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Abstract 


In  order  to  analyze  the  Advanced  Very  High  Resolution  Radiome¬ 
ter  satellite  data  from  South  Africa,  a  software  package  has  been 
written.  Methodology  and  algorithms  are  described  which  create 
geometrically  corrected  registered  satellite  images  over  the  Agulhas 
Retroflexion  region.  Also  discussed  are  programs  to  overlay  latitude 
and  longitude  lines,  ship  tracks,  and  ancillary  data.  A  method  of 
masking  the  land  and  compositing  images  for  cloud  removal  is  also 
described. 
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Introduction 


The  Woods  Hole  Oceanographic  Institution  (WHOI)  received  support  from 
the  Office  of  Naval  Research  (ONR)  and  the  National  Aeronautics  and 
Space  Administration  to  determine  the  feasibility  of  oceanographic  remote 
sensing  and  to  set  up  a  computer  remote  sensing  center.  ONR  also  funded 
research  to  study  the  Agulhas  Retroflexion  region  with  a  combined  sub¬ 
surface  mooring  array  and  satellite  imagery.  This  paper  will  describe  the 
remote  sensing  computer  facility  at  WHOI  and  the  steps  taken  to  acquire 
and  analyze  satellite  imagery  from  the  Agulhas  Retroflexion  region. 

Remote  Sensing  VAX  Processing  System 

WHOI  purchased  a  turnkey  remote  sensing  computer  system  from  ESL  In¬ 
corporated,  a  subsidiary  of  TRW,  in  Sunnyvale,  California.  ESL  provided 
the  hardware  and  software  integration  for  the  VAX /ID  IMS.  ID  IMS  is  an 
acronym  for  Interactive  Digitial  and  Image  Manipulation  System  and  refers 
to  the  software  package  on  the  specified  hardware,  the  VAX.  WHOI’s  Re¬ 
mote  Sensing  VAX  Processing  system  (RSVP),  is  based  on  the  following 
equipment: 

I.  Digital  Equipment  Corporation 


L.  (1)  VAX  11/750  central  processing  unit  (cpu) 

with  8  megabytes  of  memory,  and  a  floating  point  accelerator, 

2.  (3)  RA-81  456  megabyte  fixed  disk  drives, 

3.  (1)  RA-60  256  megabyte  removable  disk  drive  with 
(5)  removable  disk  packs, 

4.  (2)  TU78  1600/6250  bits  per  inch  (bpi)  tape  drives, 

5.  (1)  LPU-BA  line  printer, 

6.  (1)  LA120  console  terminal, 

7.  (2)  VT100  terminals, 

8.  (1)  VAX/VMS  operating  system  license,  and 

9.  (1)  Fortran,  Pascal,  and  DECNET  license. 
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II.  Gould  DeAnza  Systems 

1.  (1)  IP8500  image  processor  with 

a.  (4)  512  by  512  byte  by  8  bits  deep  image  planes, 

b.  (1)  512  by  512  byte  by  8  bits  deep  graphics  plane, 

c.  (1)  video  output  controller, 

d.  (1)  trackball, 

e.  (1)  analog  to  digital  converter,  and 

f.  (1)  digital  video  processor. 

2.  (1)  LSI  11/23  cpu  controller  with  192  kilobytes  of  memory  and 

a.  (l)  37  megabyte  Winchester  floppy  disk,  and 

b.  (1)  RSX-11  software  license. 

3.  (l)  color  monitor  and  (1)  black  and  white  monitor 
of  512  by  512  resolution. 

III.  Floating  Point  Systems 

1.  (1)  AP  120-B  array  processor 

with  64  kilowords  of  fast  main  data  memory,  and 

2.  (1)  Program  development  software  library, 

3.  (1)  Signal  Processing  software  library, 

4.  (1)  Advanced  Math  software  library,  and 

5.  (1)  Image  processing  software  library. 

ID  IMS 

The  ID  IMS  software  consists  of  functions  to  display,  process,  and  analyze 
digital  images.  ESL  originally  wrote  the  software  for  a  Hewlett  Packard 
machine,  and  later  transferred  it  to  the  VAX.  The  package  supports  a  wide 
variety  of  functions;  allowing  the  user,  for  example,  to  rotate,  classify,  mag¬ 
nify,  register,  and  filter  images.  It  also  has  a  means  to  ingest  LANDSAT 
and  Defense  Mapping  Agency  tapes;  however,  ESL  did  not  provide  the 
functions  to  process  data  from  oceanographic  satellites.  The  Scripps  Insti¬ 
tution  of  Oceanography  (SIO)  purchased  a  Hewlett  Packard  (HP)  IDIMS 
system  several  years  ago  and  spent  many  man  years  in  developing  oceano¬ 
graphic  specific  functions.  The  author  obtained  the  HP  version  of  these 
functions  and  converted  the  needed  ones  to  the  VAX  environment. 

IDIMS  uses  a  command  translator,  TRAN,  to  parse  the  user-supplied 


command  and  execute  a  function.  The  ID  IMS  command  line  syntax  is 
input  image  >  function  >  output  image. 


TRAN  executes  the  function  as  a  subprocess,  thus  allowing  the  user  to 
execute  more  than  one  function  at  a  time.  Communication  from  TRAN  to 
the  subprocess  is  done  via  a  mailbox.  Functions  which  require  extensive 
computations,  are  executed  on  the  array  processor  using  the  FPS  supplied 
libraries  and  driver.  A  detached  process,  APMON,  monitors  the  status 
of  the  array  processor  and  controls  communication  to  TRAN.  If  the  array 
processor  is  busy,  the  function  will  execute  on  the  VAX.  This  design  has 
proven  to  work  well,  giving  an  8  to  10  times  increase  in  speed  for  cpu  bound 
functions. 

Functions  which  use  the  IP8500  are  executed  differently.  The  command 
line  syntax  for  the  image  processor  functions  is 

function  func t ion _p arameters . 

To  communicate  to  the  IP8500,  the  detached  process,  DCMONA,  resides  on 
the  VAX.  A  512  byte  task  control  block  is  passed  from  TRAN  to  DCMONA 
which  transfers  the  block  over  the  Unibus  to  the  LSI.  The  LSI  parses  the 
block  and  executes  the  command  on  the  IP8500.  This  design  allows  both 
the  LSI/IP8500  and  the  VAX  to  perform  concurrent  tasks  with  DCMONA 
controlling  the  communication.  The  only  drawback  to  this  design  is  with 
tasks  that  require  extensive  communication  from  the  VAX  to  the  image 
processor,  such  as  in  VAX-computed  vector  drawing.  In  this  case,  each 
vector  drawn  from  point  A  to  point  B  would  require  one  512  byte  task 
control  block  transfer,  an  extremely  slow  process.  This  could  be  executed 
faster  by  letting  the  VAX  control  the  Input  and  Output  (I/O)  directly  to 
the  IP8500.  The  author  has  written  device  drivers  to  do  that  using  the 
Gould  DeAnza  Library  of  Image  Processing  Software  (LIPS);  however,  the 
vector  information  is  not  written  into  the  graphics  databases  on  the  LSI. 
ESL  graphics  commands,  therefore,  cannot  be  successfully  executed.  Given 
this,  the  most  efficient  method  of  drawing  vectors  is  to  write  a  graphics 
overlay  byte  image. 


AVHRR  Satellite  Data 


The  satellite  data  acquired  for  the  Agulhas  Retroflexion  analysis  was  pur¬ 
chased  from  the  Council  for  Scientific  and  Industrial  Research  (CSIR)  of 
the  National  Institute  for  Telecommunications  Research  in  Johannesburg, 
South  Africa.  The  Satellite  Remote  Sensing  Center  (SRSC)  of  CSIR  col¬ 
lected  and  distributed  the  data.  The  data  covered  the  geographic  domain 
of  25  to  45  degrees  south  by  0  to  40  degrees  east  with  a  one  day  period¬ 
icity  coverage  from  January  28,  1985,  to  January  31,  1986.  The  data  was 
air  freighted  weekly  on  computer  compatible  tapes  (cct).  The  data  was 
obtained  from  the  National  Oceanographic  and  Atmospheric  Administra¬ 
tion’s  (NOAA)  TIROS-N  sun-synchronous  series  satellites,  specifically,  the 
NOAA-7  and  NOAA-9  satellites.  The  data  was  collected  by  the  Advanced 
Very  High  Resolution  Radiometer  (AVHRR)  sensor.  The  AVHRR  is  a  five 
channel  instrument.  Two  channels  image  in  the  visible  and  near  infrared, 
.58  -  .68  micrometers  and  .725  -  1.10  micrometers.  One  channel  images 
in  the  infrared  region,  3.55  -  3.93  micrometers,  and  the  last  two  channels 
image  in  the  thermal  infrared  region,  10.5  -  11.3  micrometers  and  11.5  - 
12.5  micrometers. 

The  AVHRR  data  is  classified  as  Global  Area  Coverage  (GAC),  four 
kilometer  resolution,  or  Local  Area  Coverage  (LAC),  one  kilometer  res¬ 
olution.  Specific  satellite  receiving  stations  collect  LAC  data  over  their 
geographic  region.  The  TIROS-N  series  satellite  can  also  store  some  LAC 
data  on  board  and  then  transmit  to  a  downlink  antenna.  The  Johannesburg 
receiving  station  was  chosen  in  order  to  obtain  daily  LAC  coverage. 

The  receiving  stations  do  not  have  to  standardize  their  output  cct;  there¬ 
fore,  the  format  of  AVHRR  data  varies  greatly  depending  on  the  source. 
The  AVHRR  data  stream  is  composed  of  the  ID,  time  code,  calibration 
telemetry,  back  scan,  space  data,  sync,  tip  data,  and  the  AVHRR  count 
data.  Generally,  each  of  these  is  written  onto  a  scan  record,  although  a  site 
may  choose  to  write  only  part  of  the  auxiliary  information.  The  AVHRR 
data  sensor  collects  ten  bit  data  but  some  sites  may  choose  to  write  out 
only  eight  bit  data.  Some  sites  will  write  the  ten  bit  data  into  a  full  16 
bit  word,  while  others  may  choose  to  pack  three  ten  bit  data  into  a  full 
32  bit  word.  Because  of  these  variations,  it  is  difficult  to  write  a  general 
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purpose  AVHRR  data  entry  program.  The  simplest  method  is  to  obtain 
a  program  written  by  an  institution  such  as  Scripps,  University  of  Miami, 
or  NOAA,  and  then  make  necessary  changes  to  the  code  to  accommodate 
different  data  formats. 

The  format  specification  for  the  AVHRR  data  from  South  Africa  is  spec¬ 
ified  in  a  document  entitled  “Format  Specification  for  NOAA  -  AVHRR 
computer  compatible  tapes  produced  by  the  Satellite  Remote  Sensing  Cen¬ 
tre  of  the  Council  for  Scientific  and  Industrial  Research.”  This  document 
is  included  in  Appendix  C.  The  tape  organization  is  standard  NASA  God¬ 
dard  format;  however,  the  AVHRR  image  section  is  primarily  NOAA  High 
Resolution  Picture  Transmit  (HRPT)  minor  frame  format.  This  combina¬ 
tion  produces  a  unique  format  specification.  The  data  stream  contains  all 
the  NOAA  auxiliary  information  and  full  ten  bit  AVHRR  data  packed  into 
one  16  bit  word.  WHOI  received  ail  five  AVHRR  channels,  the  data  for  the 
pass  being  written  on  two  1600  bpi  tapes. 

The  tape  contains  one  volume  descriptor  file,  and  up  to  three  data  files 
per  tape.  The  volume  descriptor  file  contains  a  volume  descriptor  record, 
containing  information  about  the  volume  and  five  file  pointer  records  which 
axe  information  about  the  data  files.  In  theory,  one  should  be  able  to  write 
a  general  NASA  Goddard  format  tape  entry  routine  which  would  read 
the  volume  header  records  and  extract  the  imagery  data.  The  data  files 
contain  a  360  byte  descriptor  record  followed  by  2048  records  of  5596  byte 
containing  the  auxiliary  data  and  the  AVHRR  data. 

South  African  Ingest  Routines 

In  order  to  verify  and  understand  this  format,  a  program  named  SAFRAW 
was  written,  the  precursor  to  SAFENTER,  the  South  African  AVHRR  in¬ 
gest  routine.  SAFRAW  requests  number  of  lines  and  number  of  samples 
for  the  output  image,  starting  line,  starting  sample  on  the  input  tape,  line 
increment  and  sample  increment  to  skip,  and  band  number(s)  to  extract. 
The  output  image  consists  of  two  byte  AVHRR  count  data.  The  routine 
does  not  create  any  ground  control  points,  or  calibration  information,  nor 
does  it  correct  for  geometric  rotation.  To  verify  the  format  documentation, 
SAFRAW  prints  the  volume  and  file  descriptor  records,  and  the  file  pointer 


records.  This  printout  includes  the  value  and  a  description  of  the  value  for 
easy  reference.  The  file  descriptor  record  is  particularly  useful  to  determine 
the  band  number  of  the  folowing  data.  In  fact,  it  is  the  only  way  to  deter¬ 
mine  the  band  number  of  a  file,  unless  one  hardwires  band  1,  band  2,  band 
3  on  tape  number  1,  and  band  4,  band  5  on  tape  number  2.  Generally,  this 
is  true,  however,  some  tapes  have  arrived  with  different  variations.  Also 
6250  bpi  tapes  could  contain  all  data  on  one  volume. 

SAFRAW  is  a  highly  structured  Fortran  program.  If  the  program  were 
transferred  to  another  machine,  the  ID  IMS  low  level  I/O  intrinsics  would 
have  to  be  rewritten.  A  specific  subroutine  is  used  for  each  task.  The  main 
program  controls  the  flow  as  follows: 

get  input  params,  open  tape  file  and  read  volume  header, 
open  output  image,  read  tape  and  write  output  image, 
close  output  image,  close  tape  file,  rewind,  and  unload  tape 
close  output  image,  and,  finally,  error  return. 

SAFRAW  verifies  the  document  on  format  specification  but  does  not 
corect  for  geometrical  distortion.  To  correct  for  the  geometrical  distortion 
and  to  create  a  ground  control  point  file  for  subsequent  registration  to  a 
grid  are  accomplished  with  the  program  SAFENTER. 

SAFENTER  is  a  highly  modified  revision  of  the  Scripps-converted  func¬ 
tion,  TLIN.  TLIN  reads  AVHRR  archive  format  tapes  and  produces  a  ge¬ 
ometrically  corrected  ID  IMS  image. 

The  HRPT  AVHRR  archive  format  is  an  11090  byte  record,  containing 
the  following:  ID,  time,  telemetry,  back  scan,  space  data,  sync,  tip  data, 
followed  by  the  AVHRR  count  data.  The  count  data  is  arranged  in  a  line 
by  line  format,  that  is  each  scanline  contains  all  five  channels,  channel  1, 
channel  2,  etc.  for  each  2048  samples.  The  South  African  format  is  band 
by  band,  each  file  containing  only  that  channel’s  count  data.  A  conversion 
routine  could  have  been  written  to  convert  South  African  AVHRR  format 
to  archive  format,  then  TLIN  could  create  the  geometrically  corrected  im¬ 
age;  however,  this  would  require  one  extra  tape  for  each  pass  and  more 
computer  time.  Given  budget  and  space  problems,  the  author  decided  that 
this  approach  was  not  the  most  economical  nor  expedient. 

SAFENTER  is  also  a  highly  structured  portable  Fortran  program  which 


takes  advantage  of  the  TLIN  and  SAFRAW  subroutines.  The  main  pro¬ 
gram  flows  as  follows: 

get  input  parameters, 

open  tape  file  and  read  volume  header, 

print  banner, 

position  to  correct  avhrr  channel, 
read  tape  and  write  output  image, 
close  tape  file,  rewind,  and  unload  tape, 
and  finally  error  return. 

The  algorithm  for  reading  the  tape  and  creating  the  ground  control 
points  is  contained  in  SAF.TLIN.  SAF.TLIN  extracts  the  satellite  identi¬ 
fication  (id),  date,  and  start  time  of  the  pass  from  the  PASSID  parameter. 
The  PASSID  is  constructed  from  the  information  obtained  from  the  vol¬ 
ume  header.  Once  the  PASSID  is  parsed,  SAF.TLIN  reads  the  appropriate 
ephemeris  file  to  obtain  the  orbital  elements  for  the  satellite  orbit  calcu¬ 
lation.  The  elements  are  named  Charlie  elements  and  are  sent  from  the 
Naval  Space  Surveillance  System  out  of  Dahlgren,  Virginia.  The  elements 
are  sent  on  cards  once  every  two  weeks  with  a  frequency  of  every  day  and 
are  read  to  the  disk  via  a  card  reader.  They  are  sorted  by  satellite  id  and 
date  before  being  placed  into  the  master  satellite  ephemeris  file.  Upon  suc¬ 
cessful  reading  of  the  satellite  data,  SAF.TLIN  positions  the  tape  to  the 
correct  file  for  the  band  requested  and  calls  SAF.SATSENTR  to  read  the 
tape  and  compute  the  ground  control  point  list. 

SAF.SATSENTR  initializes  the  satellite  orbit  constants  and  calculates 
the  orbit.  It  then  reads  the  first  data  record  to  obtain  the  start  time.  The 
satellite  sensor  transformation  parameters,  omega  (yaw),  psi  (sight),  and 
gamma  (tilt),  are  calculated  and  then  line/sample  pairs  (198  maximum) 
are  generated  for  the  earth  location  transformation.  Determination  is  made 
whether  the  satellite  is  ascending  or  descending.  If  ascending,  the  algorithm 
requires  that  the  data  be  flipped  and  mirrored.  The  South  African  AVHRR 
data  is  stored  on  tape  so  that  the  northernmost  scanline  is  always  first.  If 
the  satellite  is  ascending,  the  southernmost  scanline  will  be  imaged  first; 
thus,  in  South  African  format,  scanline  time  will  be  incrementing  in  reverse 
order.  To  remedy  this,  a  direct  access  scratch  file  is  opened  and  the  scanline 


is  read  from  tape  and  written  back  into  the  direct  access  file  so  that  time 
will  run  sequentially.  The  first  line’s  time  value  has  been  determined  to  be 
always  incorrect  in  the  South  African  AVHRR  data.  In  order  to  obtain  a 
valid  scanline  time,  the  first  line  is  skipped  and  if  2048  lines  are  specified  as 
output,  that  last  line  will  be  replicated,  otherwise  a  premature  end  of  file 
condition  will  occur.  Once  the  scanline  is  read,  it  must  be  byte  swapped 
on  the  VAX  computer.  The  byte  swapping  is  done  specifically  for  the 
AVHRR  count  section  of  the  record  only.  The  time  word  byte  swap  is  done 
separately.  The  next  step  is  to  compute  the  geometrical  correction  table  for 
the  scanline.  The  algorithm  used  was  taken  from  Richard  Legeckis  and  John 
Pritchard’s  “Algorithm  for  correcting  the  VHRR  imagery  for  geometric 
distortions  due  to  the  earth  curvature,  earth  rotation  and  spacecraft  roll 
attitude  errors.”  The  geometrical  correction  table  is  stored  in  such  a  way 
that  the  index  into  the  table  is  the  position  of  the  sample  in  the  new  line, 
while  the  value  of  the  table  is  the  position  in  the  original  scanline  of  the 
data  value.  If  the  scanline  contains  a  ground  control  point,  then  compute 
the  times  across  the  line.  That  is,  a  198  point  ground  control  point  grid  is 
composed  of  a  14x14  matrix  of  points.  For  a  512x512  image,  every  thirty 
six  lines  of  output  will  have  a  true  ground  control  point  list.  The  times 
across  the  scanline  are  computed  with  the  following  equation,  where  N  is 
the  rotating  speed  of  the  mirror,  and  RSAMP  is  the  sample  number: 

times(indx)  —  sec  +  dble(rsamp  —  l.)/n 

The  time  word  is  extracted  from  the  auxiliary  data  by  SAF.TIME. 
Extraction  of  the  time  word  was  difficult  due  to  lack  of  adequate  docu¬ 
mentation.  SRSC  counts  the  bit  order  as  1  through  16  with  1  as  the  most 
significant  bit  and  16  as  the  least  significant  bit.  This  bit  order  is  valid 
after  the  VAX  half-word  byte  swap.  The  SRSC  documentation  states  at 
word  position  four,  bits  4  through  10  contain  the  binary  millisecond  time 
count;  however,  in  reality  SRSC  moved  these  bits  to  positions  10  through 
16  without  documentation.  Also,  the  other  bits,  1  through  9  are  non-zero. 
Since  the  first  seven  bits  axe  the  only  valid  bits,  this  halfword  must  be  log¬ 
ically  AND  with  the  hexadecimal  mask  of  7F.  The  algorithm  is  found  in 
Appendix  A,  section  I. 

Once  all  the  data  is  read  and  written  into  an  ID  IMS  image  file,  control 
is  passed  back  to  SAFJ5ATSENTR  and  the  process  starts  again  for  the 


next  band  if  so  requested.  After  all  bands  have  been  processed,  the  times 
are  converted  to  latitude/longitude  (lat/lon)  and  written  out  to  the  ID  IMS 
image  related  ground  control  point  file  and  the  process  is  completed. 

To  date,  the  calibration  phase  of  South  African  AVHRR  processing  has 
not  been  implemented.  This  would  require  extracting  the  space  scan  data 
from  the  tape  and  creating  the  ID  IMS  image  related  calibration  file. 

Figures  1  and  2  represent  the  difference  between  SAFRAW  and  SAFEN- 
TER.  The  data  was  read  from  tape  with  a  line  and  sample  increment  of 
four,  thereby  skipping  every  fourth  line  and  every  fourth  sample.  This 
created  an  output  image  of  512  by  512  pixels  and  a  spatial  resolution  of 
four  kilometers.  To  date,  SRSC  can  only  create  the  SAFRAW  type  images. 
Notice  the  image  compression  in  the  center  and  the  expansion  of  the  outer 
pixels  to  create  the  quasi-equal  area  projection  in  figure  2. 

Latitude  /  Longitude  Gridding 

To  verify  the  ground  control  point  grid,  LLGRID  was  created  to  write  a 
byte  graphics  overlay  image  of  lat/lon  grid  lines.  Originally  the  converted 
Scripps  function  EITRANS  was  used  to  create  lat/lon  lines  on  the  moni¬ 
tor  in  real  time;  however,  this  method  was  slow  due  to  the  LSI  interface. 
LLGRID  converts  the  vectors  to  raster  line  segments  and  creates  a  byte 
overlay  graphics  disk  image.  The  graphics  image  is  then  overlaid  onto  the 
monitor  image  using  the  ID  IMS  command  >  GRAPHICS. 

LLGRID  opens  the  input  image  and  the  image-related  ground  control 
point  file  if  available.  If  not  available,  it  requests  the  name  of  an  ASCII  text 
file  containing  the  ground  control  point  information.  It  then  initializes  the 
output  byte  image  to  a  user-requested  initial  value  (usually  0).  LLGRID 
then  calls  the  subroutine  EARTH  to  find  the  lat/lon  of  the  image  corners 
and  subsequently  the  extreme  minimum  and  maximum  latitude  and  lon¬ 
gitude.  To  draw  the  lat/lon  lines,  two  loops  (one  for  lat  lines,  one  for  Ion 
lines)  are  executed  between  minimum  and  maximum  latitude  and  between 
minimum  to  maximum  longitude  with  an  increment  of  the  user  requested 
tick  interval.  A  call  to  EARTH  is  made  to  convert  the  incremented  lat/lon 
to  line/sample  coordinates.  If  the  line/sample  is  found  to  be  within  the 
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Figure  1:  A  512  by  512  byte  AVHRR  count  image  of  South  Africa  and  the 
Southern  Indian  Ocean  taken  on  March  26,  1985.  The  image  was  created  by 
the  function  SAFRAW  with  every  fourth  line  and  sample  read  from  band 
four  on  the  AVHRR  tape.  The  sourthern  part  of  Africa  is  clearly  visible  in 
the  top  middle  of  the  image.  The  Agulhas  Retroflexion  region  is  partially 
obscured  by  clouds  to  the  south  of  the  African  continent.  The  Agulhas  cur¬ 
rent  appears  black  while  white  represents  the  coldest  temperature  values. 
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Figure  2:  The  same  image  as  Figure  1,  except  created  by  SAFENTER. 
Geometric  distortions  due  to  earth  curvature  and  rotation  were  corrected. 
Compare  the  image  compression  in  the  center  and  the  expansion  of  the 
outer  pixels  from  Figure  1. 
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image  dimension  size,  the  point  is  saved.  Once  two  iine/sample  points  are 
known,  a  vector  to  raster  line  conversion  routine  is  executed  to  create  a  list 
of  raster  line/sample  points  that  connect  the  initial  two  lat/lon  points.  The 
grey-level  image  value  at  the  line/sample  points  is  converted  from  the  initial 
value  to  the  user-requested  grid  value  (usually  255).  LLGRID  verifies  the 
correctness  of  the  ground  control  point  grid  obtained  from  SAFENTER. 
Figure  3  is  the  same  image  as  figure  2,  but  with  the  addition  of  the  lat/lon 
grid  overlay.  Notice  the  quasi-equal  area  projection. 

Image  Registration 

The  next  step  is  to  warp  (or  register)  the  image  to  a  user  specified  map 
projection.  The  user  specifies  a  grid  by  defining  a  set  of  control  points, 
in  an  ASCII  file,  that  determine  the  projection.  This  allows  the  user  to 
have  complete  control  over  the  type  of  projection.  The  Scripps-converted 
program  MAKEGRID  requests  center  latitude,  center  longitude,  pixel  size, 
rectangular  or  mercator  projection,  rotation  angle,  and  grid  size,  and  then 
computes  and  creates  the  ASCII  text  ground  control  point  (gcp)  file.  The 
ASCII  gcp  text  file  contains  the  pointname,  line,  sample,  latitude,  and  lon¬ 
gitude  of  selected  control  points.  The  registration  is  done  with  the  Scripps 
converted  function  AUTO  REG. 

AUTOREG  computes  a  transform  from  the  image  gcp  file  to  the  user 
supplied  gcp  file.  The  transform  coefficients  are  saved  in  an  ID  IMS  file  to  be 
used  by  the  ESL  supplied  REGISTER  function  which  does  the  actual  image 
warping  in  the  array  processor.  AUTOREG  requests  from  the  user  the 
name  of  the  ASCII  gcp  text  file,  the  degree  of  the  interpolating  polynomial, 
and  the  file  name  for  the  output  transform  coefficients.  The  input  picture 
image  is  opened  to  obtain  the  ground  control  point  transform  coefficients, 
and  a  temporary  image  is  created  to  attach  the  registered  gcp  file.  The  user 
supplied  ASCII  text  file  is  then  opened  and  read  to  obtain  the  new  ground 
control  point  information.  Each  control  point  in  the  user  supplied  gcp  file 
is  converted  from  a  lat/lon  to  the  image’s  equivalent  line  and  sample.  If 
the  line  and  sample  axe  not  on  the  image,  the  point  is  not  included  in 
the  new  line/sample  array.  The  transform  coefficients  are  then  computed 
from  this  new  line/sample  gcp  array  and  are  stored  in  the  ID  IMS  transform 
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Figure  3:  The  same  image  as  Figure  2  except  with  a  latitude  and  longitude 
grid  embedded  into  it.  The  latitudes  and  longitudes  are  marked  at  every 
five  degree  increments.  Notice  the  quasi-equal  area  projection. 
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file.  Once  the  transform  coefficients  are  known,  a  new  image  gcp  file  can 
be  created.  Each  line/sample  control  point  of  the  image  is  converted  to 
the  new  line/sample  with  the  new  transform  coefficients.  The  new  gcp  file 
is  then  attached  to  the  temporary  image  and  the  REGISTER  function  is 
executed  to  do  the  warping.  After  successful  completion  of  the  registration, 
the  function  APPEND  written  by  the  author  is  executed  to  attach  the  gcp 
file  created  from  AUTO  REG  to  the  new  image. 

The  REGISTER  function  computes  the  location  of  the  new  image  co¬ 
ordinate  by  a  reverse  transformation  equation,  since  the  new  output  is 
computed  line  by  line.  For  a  degree  three  polynomial  (the  highest  degree 
available)  the  following  equation  is  used  to  determine  the  location  from  the 
input  image  for  the  specified  output  line  and  sample. 

IL=input  line,  IS=input  sample,  OL=output  line,  OS=output  sample 

IL  =  A(0)  +  A(l)  *  OL  +  A{ 2)  *  OS  +  A(3)  *  OL 2  +  A(4)  *  OSJ+ 

A(5)  *OL*OS  +  A( 6)  *  OL3  +  A{ 7)  *  OS3 

IS  =  5( 0)  +  5(  1)  *  OL  +  B{ 2)  *  OS  +  5(3)  *  OL3  +  5(4)  *  OS2+ 
5(5)  *OL*OS  +  5(6)  *  OL  *  *3  +  5(7)  *  OS3 

For  a  simple  translation  of  two  pixel  locations  in  the  line  direction, 
A(0)  =2  ,  A(l)  =  1 , 5(2)  =  I  the  rest  of  the  A  and  B  coefficients  would 
equal  0.  The  equations  would  collapse  to: 

IL  =  2  +  OL 
IS  =  OS. 

In  most  cases,  the  image  grey  level  value  at  the  input  image  location 
will  be  between  input  pixels;  therefore,  the  output  pixel  value  is  determined 
by  nearest  neighbor,  bilinear  or  cubic  convolution  interpolation.  Nearest 
neighbor  interpolation  will  return  the  value  of  the  closest  pixel.  With  bi¬ 
linear  interpolation,  the  output  value  is  determined  by  taking  a  weighted 
average  of  the  values  of  the  four  nearest  input  points.  If  cubic  convolution 
interpolation  is  selected,  then  the  output  value  is  determined  by  using  third 
order  spline  functions  to  fit  the  value. 

Upon  completion  of  these  steps,  image  data  can  be  read  from  tape  and 
mapped  to  a  common  geographical  grid.  Figure  4  is  the  same  image  as  fig¬ 
ure  2  but  registered  using  the  grid  points  from  the  ASCII  file  SAF198.GRD. 


SAF198.GRD  is  the  common  geographical  grid  chosen  for  the  South  African 
AVHRR  data  and  has  a  geographic  center  at  37  degrees  9  minutes  south, 
26  degrees  2  minutes  east.  It  is  included  as  Appendix  B.  This  projection 
and  center  provided  the  optimum  viewing  geometry  for  the  mooring  array 
and  the  land  boundaries. 


Land  Masking 


For  analyzing  purposes,  it  is  helpful  to  mask  the  land  with  a  specified  bright¬ 
ness  value.  For  most  purposes,  the  brightness  value  will  be  zero  (black)  on 
a  monitor  and  255  (white)  for  a  laser  print.  The  function  SAFMASK  was 
written  to  mask  out  the  land  and  uses  the  CIA’s  World  Data  Base  (WDB) 
II  to  delineate  land  from  coast.  WDB  II  is  a  one  kilometer  data  base 
containing  latitudes  and  longitudes  of  the  world’s  coastline.  Once  a  coast 
is  computed,  a  polygon  fill  technique  is  used  to  fill  the  land  region.  At 
present,  only  the  viewing  geometry  selected  for  the  South  African  data  is 
valid  for  the  SAFMASK  routine;  although,  with  very  slight  modifications 
all  viewing  geometries  could  be  used. 

SAFMASK  requires  a  maximum  size  image  of  512  by  512  bytes.  It 
uses  the  IDIMS  image-related  gcp  file  to  compute  the  lat/lon  coordinates 
of  the  image.  If  a  gcp  file  does  not  exist  for  the  image,  then  the  user  is 
requested  to  input  the  name  of  the  user  supplied  ASCII  text  gcp  file.  The 
minimum  latitude  and  longitude  is  computed.  If  a  lat/lon  point  on  the 
image  is  a  coastline  point,  then  the  lat/ion  is  converted  to  line/sample. 
The  user  supplied  mask  value  is  written  to  the  output  image  at  that 
line/sample  position.  A  number-of-points  array  is  updated  to  indicate 
the  number  of  coastline  data  points  in  the  scanline.  This  variable  is  la¬ 
beled  NUMPTS.  Also  the  line/sample  position  is  stored  in  a  two  dimen¬ 
sional  array  to  indicate  coastline.  This  array  is  labeled  YXLINE.  YX- 
LINE(NUMPTS(SCANLINE), SCANLINE)  is  equal  to  the  last  sample  in 
SCANLINE  that  was  determined  to  be  the  coastline.  Note  that  this  point  is 
not  the  maximum  sample  in  the  YXLINE  array  at  line  number  SCANLINE. 
Once  the  coastline  is  computed,  the  masking  is  started. 

For  the  masking,  a  fill  flag  array  from  1  to  the  number  of  lines  in  the 
image  is  set  to  false.  A  loop  is  performed  from  1  to  the  number  of  lines. 
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The  points  in  the  YXLINE  are  ordered  from  minimum  sample  to  maximum 
sample.  If  the  scanline  has  only  two  coastline  points,  then  the  scanline  is 
filled  with  the  mask  value  from  the  minimum  coast  position  to  the  maximum 
coast  position.  The  fill  flag  for  the  scanline  is  set  to  true,  indicating  that 
the  scanline  has  been  filled. 

Since  the  image  is  a  raster  image,  a  coastline  point  may  be  a  single 
point,  or  a  raster  line  segment.  If  the  scanline  does  not  have  two  coast¬ 
line  points,  then  either  the  scanline  does  indeed  have  more  than  two  dis¬ 
tinct  coastline  crossings,  or  the  coastline  points  have  been  drawn  with 
raster  line  segments.  A  check  is  made  to  determine  the  “true”  number 
of  coastline  points.  If  two  coast  points  in  the  YXLINE  array  have  a  dif¬ 
ference  of  one,  then  they  are  adjacent  to  each  other,  and  the  number  of 
points  variable  is  reduced.  If  the  true  number  of  points  is  equal  to  2, 
then  the  scanline  does  indeed  have  only  two  coastline  crossings,  and  the 
line  is  filled  with  the  mask  value  from  YXLINE(l, SCANLINE)  to  YX- 
LINE(NUMPTS (SCANLINE), SCANLINE).  The  fill  flag  is  set  to  true  for 
this  scanline  and  the  next  line  is  tested.  If  the  scanline  falls  through  both 
of  these  tests,  then  a  check  is  made  to  determine  if  the  minimum  and 
maximum  coast  points  are  within  one  value  of  the  previously  filled  line’s 
minimum  and  maximum  coast  points.  If  so,  then  the  scanline  is  filled  from 
the  minimum  to  the  maximum  coast  points,  since  the  coastline  is  a  closed 
polygon.  The  next  line  is  tested  until  a  scanline  has  no  coastline  points, 
then  the  loop  is  terminated,  with  QUITLINE  being  assigned  the  last  line 
number. 

The  next  loop  goes  in  reverse  order  from  QUITLINE  to  1.  The  loop 
tests  for  an  unfilled  line.  If  the  scanline  has  not  been  filled,  then  a  test  is 
made  to  find  the  nearest  preceding  or  succeeding  filled  line.  Once  found,  a 
loop  is  made  from  each  scamline’s  coast  points.  These  points  cam  be  called 
the  local  minimum  and  local  maiximum  points.  If  this  line  is  filled  between 
the  unfilled  scanlines  coast  points,  then  the  unfilled  line  is  filled  between 
its  coaist  points  within  a  loop.  Once  all  the  lines  have  been  tested,  the  lamd 
is  completely  filled,  files  are  closed  and  the  function  terminates.  The  lamd 
mask  cam  then  be  overlaid  onto  the  monitor  or  embedded  into  the  image 
using  the  OR  or  AND  function,  depending  on  the  mask  value  for  the  lamd. 
An  example  of  SAFMASK  is  figure  5  which  is  the  same  image  as  figure  4 


with  the  addition  of  the  land  mask.  The  Fortran  code  for  the  fill  algorithm 
is  found  in  Appendix  A,  section  II. 


Vector  Overlays 

Once  the  image  has  been  registered,  the  analyst  may  wish  to  overlay  ancil¬ 
lary  data,  such  as  buoys,  ship,  XBT,  or  float  tracks  onto  the  image.  The 
analyst  may  also  wish  to  examine  (profile)  the  line,  sample,  latitude,  longi¬ 
tude,  and  image  values  from  point  A  to  point  B  on  the  image.  The  routine 
written  to  perform  these  multi-purposed  functions  is  named  ITRACKS. 

For  overlaying  ancillary  data,  ITRACKS  accepts  a  user  file  of  positions 
to  plot  on  a  graphics  overlay  file.  The  format  of  the  user  file  is  as  follows: 

pointname,  line,  sample,  latitude,  longitude,  point.value,  sort_key. 

If  a  value  is  not  known,  0.0  is  used.  ITRACKS  will  connect  all  points  with 
the  same  sort  key  value.  It  will  connect  the  points  with  a  single  black  and 
white  intensity  value,  or  draw  the  vector  with  a  red,  green,  and  blue  (color) 
value. 

ITRACKS  also  allows  the  user  to  profile  the  image  from  user-supplied 
monitor  trackball  positions.  Two  points  are  selected  by  the  amalyst  with 
the  trackball.  A  line  is  drawn  on  the  monitor  from  the  first  point  to  the 
second  and  then  the  line,  sample,  latitude,  longitude,  atnd  real  image  values 
for  the  line  are  printed  on  the  terminal.  This  allows  the  analyst  to  quickly 
determine  interesting  feature  values  and  their  positions. 

The  flow  of  ITRACKS  is  as  follows:  ITRACKS  verifies  that  the  input 
image’s  size  is  less  than  or  equal  to  512  bytes  by  512  bytes.  It  then  tries  to 
read  the  ID  IMS  image- related  gcp  file  to  obtain  the  ground  control  point 
transformation.  If  not  found,  the  parameter  prompter  will  prompt  for  the 
user  supplied  ASCII  gcp  file.  The  parameter  prompter  is  called  to  acquire 
the  GRIDVAL  and  COLOR  values.  GRIDVAL  is  the  intensity  value  for  the 
black  and  white  track  lines.  The  default  value  is  255,  white.  The  COLOR 
value  is  YES  for  color  vectors  and  NO  for  grey  level  vectors.  The  default  is 
NO.  The  prompter  will  also  prompt  for  the  ASCII  gcp  file  if  needed.  Once 
the  parameter  values  are  checked,  then  the  output  image  is  opened.  If  the 
COLOR  option  has  been  selected,  then  the  input  single-handed  image  is 
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converted  to  an  output  three-banded  image.  This  is  done  by  reading  the 
single  band  input  image  and  writing  the  single  band  out  three  times,  once 
for  the  red  channel,  once  for  blue,  and  once  for  green.  With  equal  values  for 
red,  green,  and  blue,  the  three-banded  image  will  still  be  various  intensities 
of  black  and  white.  This  is  done  in  order  to  create  colors  for  the  vector 
tracks.  The  vector  tracks  are  then  actually  embedded  into  the  image,  not 
overlaid.  The  next  step  is  to  compute  the  minimum  and  maximum  latitude 
and  longitude. 

If  COLOR  is  requested,  then  the  analyst  is  prompted  to  determine  if  a 
color  bar  is  required.  The  color  bar  is  a  wedge  of  the  colors  of  the  tracks 
that  will  appear  on  top,  bottom,  left,  or  right  of  the  image,  depending  on 
the  analyst’s  request.  If  the  color  bar  is  selected,  then  the  analyst  will  also 
supply  the  pixel  size  of  each  bar  (default  is  12  by  12)  and  the  color  interval. 
This  allows  the  analyst  to  have  different  colors  for  tracks  depending  on 
a  data  value  at  the  track  position.  Minimum  and  maximum  data  value 
ranges  are  also  requested  if  known.  This  allows  the  user  to  specify  a  range 
of  values,  even  though  the  data  may  not  fully  reside  from  minimum  to 
maximum  value.  TRK_COLOR  is  called  to  compute  the  color  table  for  the 
data  values.  Given  the  minimum  and  maximum  of  the  data  values  and  the 
user  supplied  color  interval,  TRK-COLOR  will  compute  the  color  bins  for 
the  data  range.  The  number  of  color  bins  will  equal 

( rmax  —  rmin)  /  user -interval  +  1. 

It  will  then  compute  the  color  minimum  and  color  maximum  and  print 
a  color  table.  The  table  will  have  a  data  value  and  a  color  name.  The 
red,  green,  and  blue  combination  for  the  colors  are  in  a  look-up  table.  A 
maximum  of  15  colors  is  available.  The  colors  are  red,  light  red,  light 
orange,  orange,  yellow,  light  green,  green,  dark  green,  blue  green,  aqua, 
light  blue,  blue,  dark  blue,  violet,  and  dark  violet. 

ITRACKS  then  prompts  for  more  commands  with  its  own  internal  com¬ 
mand  prompter:  ENTER  COMMAND  >  .  The  valid  commands  are: 

END  -  to  end  the  session, 

LAT/LON  -  for  latitude/ longitude  input  coordinates 
converted  to  line  sample  output  points, 

LINE/SAMPLE  -  for  line/sample  input  coordinates 
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TEXT 

PRO 


converted  to  lat/lon  output  points, 

-  for  text  input  of  data  values,  and  finally, 

-  for  profiling  option. 


If  TEXT  is  typed,  then  the  file  name  and  data  type,  vector  or  scalar,  axe 
requested.  If  the  input  data  is  scalar,  then  the  begin  and  end  sort  key  are 
also  requested.  For  scalar  input,  all  data  that  lies  between  begin  and  end 
sort  key  are  drawn  with  one  continuous  line.  The  text  file  is  opened  and 
each  pointname,  line,  sample,  latitude,  longitude,  data.value,  and  sort_key 
are  read.  If  the  point’s  key  is  not  within  the  key  range,  then  the  point  is 
not  drawn.  If  within  the  range,  the  lat,  Ion  axe  converted  to  line,  sample. 
The  raster  line  segment  between  successive  points  is  calculated.  If  the  line 
is  not  to  be  colored,  the  line  is  drawn  by  replacing  each  raster  point  in  the 
line  with  the  GRIDVAL.  Also,  for  each  line,  sample,  the  latitude,  longitude, 
data_value,  and  image_value  axe  output  to  the  terminal.  If  the  line  is  to  be 
colored,  then  the  data  value  is  binned  to  acquire  the  correct  color  value, 
that  is, 


color_bin  =  (  data.value  -  data_minimum  )/interval  +  1  . 

The  red,  green,  and  blue  values  are  extracted  from  the  RGB  table  for  that 
color  bin  and  the  line  is  drawn  with  these  values  for  the  three  bands.  Once 
all  the  points  have  been  drawn,  the  color  bar  is  output  onto  the  image  if 
requested. 

Processing  of  vector  input  is  performed  similarly.  The  text  file  is  opened 
and  the  pointname,  line,  sample,  latitude,  longitude,  directional  vectors  ux, 
uy,  and  key  are  read.  The  point  is  converted  to  line  sample  if  needed.  The 
vectors  are  scaled  by  the  user-supplied  magnitude  divided  by  the  magnitude 
of  the  longest  vector.  The  vector  is  drawn  from  the  line,  xl,  and  sample, 
yl,  of  the  input  data  to  the  calculated  positions  x2,  y2: 


x2  =  ux  *  scale  +  xl 
y2  =  uy  *  scale  -I-  yl 


An  arrow  is  also  drawn  at  the  top  of  the  vector.  Once  all  the  vectors  have 
been  drawn,  the  program  returns  to  the  COMMAND  prompt. 

If  the  PROFILE  command  was  selected,  then  the  cursor  appears  on  the 
monitor  and  the  user  selects  the  beginning  and  ending  points.  A  line  is 
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drawn  on  the  monitor  from  the  beginning  to  the  end  points.  The  drivers 
that  perform  these  manipulations  were  not  part  of  the  standard  ID  IMS 
package  and  were  written  by  the  author.  Once  the  line  is  drawn  on  the 
monitor,  the  corresponding  line(s)  and  sample(s)  are  extracted  from  the 
image  and  the  latitude(s)  and  longitude(s)  are  calculated.  These  values  are 
printed  to  the  terminal  and  the  process  is  repeated  until  the  END  trackball 
button  is  pushed.  Control  then  returns  to  the  COMMAND  prompt. 

At  the  COMMAND  prompt,  END  will  terminate  the  function  and  the 
output  image  will  be  closed.  An  example  from  ITRACKS  is  figure  6  display¬ 
ing  the  XBT  measurements  and  mooring  positions  on  the  figure  5  image. 


Cloud  Composite 


The  Agulhas  Retroflexion  region  is  extremely  cloudy.  During  1985,  12  days 
were  marked  as  “good”  and  reasonably  cloud-free  in  the  Retroflexion  region, 
86  days  were  reasonably  cloud-free  elsewhere.  To  try  to  obtain  a  surface 
expression  through  the  clouds,  a  composite  was  made  of  several  succeed¬ 
ing  days  during  the  best  cloud-free  week.  A  function  named  COMPOSIT 
performed  this  feature  with  a  maximum  of  three  input  images. 

Several  cloud  masking  algorithms  have  been  developed  during  the  years. 
Some  use  Fourier  transform  techniques  while  others  use  the  difference  be¬ 
tween  channels  three  and  four  and  require  repetitive  iterations  and  many 
user  inputs.  A  simple  method  for  compositing  is  to  assign  a  cloud  threshold 
value.  Any  pixel  that  is  colder  than  the  threshold  value  is  considered  cloud. 
This  is  the  method  that  COMPOSIT  uses.  This  method  is  preferred  over 
an  average  technique  which  tends  to  “smear”  the  thermal  features.  A  bet¬ 
ter  method  would  be  to  create  a  cloud  mask  using  more  than  just  a  cutoff 
value  for  cloud  determination,  but  not  requiring  massive  reiterations  or  user 
inputs.  Once  this  was  achieved,  a  Markov  process  chain  could  be  developed 
to  replace  the  cloud  value  over  a  region  with  its  probability  thermal  value. 

For  the  COMPOSIT  algorithm,  images  must  be  mapped  so  that  low 
temperatures  are  high  intensity  values,  which  is  the  AVHRR  count  repre¬ 
sentation.  COMPOSIT  requests  the  minimum  intensity  value  to  denote 
cloud  cutoff.  Any  pixel  that  is  greater  than  the  cloud  cutoff  value  is  consid- 
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ered  cloud.  It  then  opens  and  reads  the  three  input  images.  If  a  pixel  from 
the  first  image  is  greater  than  or  equal  to  the  cloud  value,  then  that  pixel  is 
replaced  with  the  lowest  intensity  value  (the  warmest  temperature)  of  the 
two  other  images,  otherwise,  it  is  written  to  the  output  buffer.  Once  the 
scanline  has  been  processed,  it  is  written  to  the  output  image.  An  example 
of  the  COMPOSIT  function  is  given  in  figure  7. 


Laser  Printer  Output 


At  present,  images  can  be  outputted  either  on  the  Matrix  4007  multi- 
formatting  camera  on  35  mm  or  8x10  film,  or  with  the  QMS  800  Laser 
Printer.  For  report  and  working  purposes,  the  laser  printer  is  a  useful  out¬ 
put  device.  To  automate  the  process,  a  set  of  command  files  was  written  to 
read  the  AVHRR  tape,  to  register,  map,  and  mask  the  image,  and  finally 
to  output  it  to  the  QMS  printer.  The  command  files  are  written  in  the 
ID  IMS  command  language  and  axe  a  set  of  ID  IMS  commands  written  in  an 
ASCII  file.  A  command  file  to  read,  register,  and  mask  an  image  is  found 
in  Appendix  A,  section  III. 

The  next  step  is  to  create  a  QMS  file  to  print  on  the  laser  printer.  VMS 
commands  axe  used  for  this  purpose.  The  Information  Processing  Center 
Laboratory’s  (IPCL)  program  EMGQMS  converts  the  byte  file  QMS. DAT 
to  a  QMS  file  with  halftone  dithering  patterns.  First  append  the  file  to  a 
header  file,  QMS. IMG,  for  EMGQMS: 


$  APPEND  QMS. DAT  QMS. IMG 

run  the  IMGQMS  program  with  halftone  dithering, 

$  IMGQMS/HALF  QMS. IMG 

and  finally  print  the  output  file,  UNIQMS.DAT  on  the  QMS  printer, 
$  PRINT/QUE=QMSPRINT/NOFORM  UNIQMS.DAT. 


Conclusion 


In  conclusion,  many  functions  and  routines  were  written  by  the  author  to 
support  the  remote  sensing  effort  in  the  Agulhais  region.  It  is  extremely  im¬ 
portant,  however,  to  realize  that  without  a  skeletal  system,  mainly  IDIMS 
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Figure  7:  The  same  image  as  Figure  5  except  with  some  clouds  removed 
by  the  COMPOSIT  routine.  Images  from  March  25  and  March  27  were 
registered  to  the  same  grid  as  for  the  March  26  image.  To  create  Figure  7, 
each  pixel  was  replaced  by  the  warmest  value  in  the  three  day  time  period. 
Notice  the  removal  of  clouds  in  the  Agulhas  current  and  the  Retroflexion 


with  the  Scripps-converted  functions,  many  more  low  level  routines  would 
have  had  to  be  written.  This  effort  would  have  been  extremely  time- 
consuming  and  non-productive. 

Remote  sensing  must  be  considered  as  an  interdisciplinary  effort.  It 
requires  an  engineering  viewpoint  to  understand  the  mechanics  of  image 
processing  and  software  development,  a  physics  viewpoint  to  understand 
the  satellite  orbital  mechanics,  and  an  oceanographic  viewpoint  to  grasp 
the  underlying  principles  of  the  ocean  dynamics. 
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APPENDIX  A  -  ALGORITHMS 

I.  TIME  WORD  EXTRACTION  ALGORITHM  FOR  SAFENTER 

C 

C  Algorithm  to  extract  and  compute  the  time  word  from 
C  the  SRSC  AVHRR  data  stream. 

C 

C  Obtain  the  three  word  time  count. 

C 

DO  1=1,3 

TIMEBUFFER(I)=INTBUFFER(9+I) 

END  DO 

Byte  swap  the  half  words  (three  half  words). 

CALL  BYTE_SWAP(I2_TIME,2,0,1,3) 

AND  the  seven  most  significant  bits  of  the  most  significant 
half  word  to  zero  the  remaining  VAX  high  order  bits. 

AND_VALUE=‘7F’X 
MS1=I2_TIME(1).AND.AND_VALUE 


Move  the  bits  to  correct  significant  position, 


MS2=I2.TIME(2) 

MS3=I2_TIME(3) 

MS1=MS1*2**20 

MS2=MS2*2**10 


then  add  them  all  up. 


SEC=MS1+MS2+MS3 
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II.  LAND  FILL  ALGORITHM  FOR  SAFMASK 

Statement  is  true  if  coastal  points  have  been  found  in  the  image. 

890  IF  (NEXTK.GT.l)  THEN 

Set  up  the  byte  output  mask  value. 

Output  mask  value  will  be  BMINVAL. 

OUTBUF=COASTVAL 

BMINVAL=B4(1) 

First  loop  for  all  scanlines,  set  fill  flag  to  false  for  all  lines. 

QUIT=0 
DO  1=1, NL 
FILL(I)=. FALSE. 

C 

C  If  statement  is  true,  line  contains  no  coast  points, 

C  and  assuming  processed  all  African  coast/land. 

C  Branch  out  of  loop  and  process  backward  from  QUITJLINE  to  line  1 
C 

IF(NUMPTS(I).LT.l)  THEN 
QUIT=QUIT+1 
QUITXINE=I 
GO  TO  9003 
END  IF 
C 

C  Statement  not  true,  found  coast  points, 

C  obtain  I’th  output  scanline  with  coast  points. 

C 

CALL  READP  (UICB,IND,ODSRN,INTBUF,l,l,I,l,NS,l,i+l,l,NS) 
C 

C  Winpts  is  a  temporary  count  of  the  number  of  coast  points. 

C  If  2  coastal  points,  fill  the  scanline. 
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c 

WINPTS=NUMPTS(I) 

IF(NUMPTS(I).EQ.2)  GO  TO  8901 
LMIN=512 
LMAX=1 
KK=1 
C 

C  Order  the  coastal  points  min  to  max. 

C  yxline(l,i)  will  equal  the  minimum  sample  coast  point. 

C  yxline(numpts(i),i)  will  equal  the  maximum  sample  coast  point 
C  in  the  I’th  scanline,  after  min  to  max  ordering. 

C 

8902  IF(KK.EQ.NUMPTS(I))  GO  TO  8903 
DO  K=KK,NUMPTS(I) 

IF(YXLINE(KK,I).GT.YXLINE(K,I))  THEN 
ITEMP=YXLINE(K,I) 

YXLINE  (K,I)  = YXLINE(KK,I) 

YXLINE  (KK, I) =ITEMP 
END  IF 
END  DO 
KK=KK+1 
GO  TO  8902 
C 

C  Find  TRUE  NUMPTS,  ie  a  line  segment  is  actually  one  coast  crossing. 
C  If  the  coastal  points  are  adjacent,  then  decrement  the  temporary 
C  number  of  points  value,  winpts. 

C  Start  with  minimum  side  (  left  side  ) 

C  then  do  maximum  side  (  right  side  ). 

C 

8903  LMIN= YXLINE  (1,1) 

LMAX=YXLINE(NUMPTS(I),I) 

MN=LMIN 
MX=LMAX 

Do  the  minimum  side  first,  (  left  side  ) 
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checking  for  coastline  segment,  ie  adjacent  pixels. 


DO  K=1,NUMPTS(I) 
IF(ABS(MN-YXLINE(K,I)).EQ.l)  THEN 
these  two  points  are  adjacent 
MN=YXLINE(K,I) 

WINPTS=WINPTS-1 
END  IF 


Do  the  maximum  side  (  right  ). 

IF(ABS(MX-YXLINE(NUMPTSfI)-K+l,I)).EQ.l)  THEN 
MX=YXLINE(NUMPTS(I)-K+1,I) 

WINPTS=WINPTS-1 
END  IF 
END  DO 
C 

C  Is  there  only  two  “true”  coast  crossings? 

C  If  so,  then  can  fill  from  the  minimum  coast  crossing  to  the  maximum. 

C 

8901  IF(WINPTS.EQ.2)  THEN 
MASK=.TRUE. 

LMIN=YXLINE(1,I) 

LMAX=YXLINE(NUMPTS(I),I) 

C 

C  Fill  the  line  with  the  mask  value  from  minimum  coast  value  to  max, 

C  set  fill  flag  to  true,  and 
C  write  the  line  to  the  output  image. 

C 

DO  K=LMIN,LMAX 
BBUF(K)=BMINVAL 
END  DO 
FILL(I)=.TRUE. 

CALL  WRITEP  (UICB,IND,ODSRN,INTBUF,l,l,I,l,NS,l,i+l,l,NS) 
GO  TO  9002 
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c 

C  No  two  coast  points, 

C  test  if  previous  filled  line  min  and  max  coast  points  are 
C  within  ONE  of  this  line’s  min,  max  points.  If  so,  fill  the  line 
C  this  will  fill  internal  lakes,  etc. 

C 

IF  (MASK)  THEN 

IF(ABS(LMIN-LMINP).LE.l.AND.ABS(LMAX-LMAXP).LE.l)  THEN 
Fill  the  line,  set  fill  flag,  write  line  to  output  image. 


DO  K=LMIN,LMAX 
BBUF(K)=BMINVAL 
END  DO 
FILL(I)=.TRUE. 

CALL  WRITEP  (UICB,IND,ODSRN,INTBUF,l,l,I,l,NS,l,i+l,l,NS) 
C  Get  next  line. 

GO  TO  9002 
END  IF 
END  IF 
C 

C  Unfilled  line  -  just  put  the  coast  points  back  into  the  line 
C  buffer  and  write  back  out. 

C 

MASK=. FALSE. 

DO  K=1,NUMPTS(I) 

BBUF(YXLINE(K,I))=BMINVAL 
END  DO 

CALL  WRITEP  (UICB,IND,ODSRN,INTBUF,l,l,I,l,NS,l,i-f  1,1, NS) 
C 


C  End  of  first  loop,  save  the  line’s  coast  min  and  max  value. 

C 

9002  LMINP=LMIN 
LM  AXP = LM  AX 
END  DO 

C 

C  Now  go  backwards. 

C  Quit  Jine  speeds  up  the  fill  process  and  also  prevents 
C  possible  islands  from  being  filled  that  is  south  of  the  southernmost 
C  tip  of  AFRICA. 

C 

9003  DO  I=QUIT .LINE, 1,-1 
C 

C  Is  this  a  valid  unfilled  line  -  if  so  get  valid  next  fill  line. 

C 

IF(.NOT.FILL(I))  THEN 
ILINE=0 
C 

C  Find  the  previous  or  succeeding  filled  line,  and 
C  set  that  line  to  iline. 

C 

IF(FILL(I+1))  THEN 

ILINE=I+1 

ELSE 

IF(FILL(I-1))  ILINE=I-1 
END  IF 

IF(ILINE.GT.QUIT-LINE.OR.ILINE.LT.l)  GO  TO  9004 
C 

C  Obtain  the  filled  line  and  the  unfilled  line  from  the  image. 

C 

CALL  READP  (UICB,IND,ODSRN,INTBUF,l,l,ILINE,l,NS,l,i+l,l,NS) 
CALL  READP  (UICB,IND,ODSRN,bbuf2,l,l,I,l,NS,l,i+l,l,NS) 

C 

C  Loop  on  the  number  of  coast  points. 

C 
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DO  K=1,NUMPTS(I)-1 


C 

C  If  the  filled  line  is  filled  at  the  unfilled  k’th  coast  point  +  1, 

C  and  the  filled  line  is  filled  at  the  unfilled  k+1  coast  point  -1, 

C  then  fill  between  the  k’th  to  the  k+1  coast  point. 

C  For  example,  if  x  denotes  filled  or  coast  point,  then  if  the  scanlines 
C  look  like  the  following,  then  fill  between  the  coast  points 
C  filled  line  xxxxxxxxx 
C  unfilled  line  xx  x 
C 

IF (  (BBUF (YXLINE (K,I) + 1)  .EQ  .BMINVAL) 

.AND. 

(BBUF (YXLINE(K+1,I)-1).EQ. BMINVAL)  )  THEN 
C 

C  lmin  =  k’th  coastal  point 
C  lmax  =  k+1  coast  point 
C  Fill  the  line  between  the  two. 

C 

LMIN=YXLINE(K,I) 

LMAX= YXLINE  (K+ 1 , 1) 

DO  L=LMIN,LMAX 
BBUF2(L)=BMINVAL 
END  DO 
FILL(I)=.TRUE. 

END  IF 
END  DO 

Write  the  line  out. 


CALL  WRITEP  (UICB,IND,ODSRN,bbuf2,l,l,I,l,NS,l,i+l,l,NS) 
END  IF 


III.  ID  IMS  COMMAND  FILE  FOR  LASER  PRINTING 

C: 

C:  The  syntax  for  a  comment  line  is  C:  and  for  a  continuation  of  a 
C:  command  line  a  +  is  used. 

C: 

C:  Read  the  South  African  AVHRR  tape  and  create  an  IDIMS  image. 
C: 

C:  The  image  will  be  512  lines  (NL=512)  and  512  samples  (NS=512). 
C:  The  starting  line  and  starting  sample  will  be  1  (SL=1,  SS=1). 

C:  Skip  every  fourth  line  and  every  fourth  sample  on  the  input  tape 
C:  (LINEINC=4,  SAMPINC=4) 

C:  and  read  Band  number  4  (BANDLIST=4). 

C: 

C:  The  output  image  name  will  be  DATE. 

C: 

>  SAFENTER(NL=512,  NS=512,  SL=1,  SS=1,  LINEINC=4,  + 
SAMPINC=4,  BANDLIST=4)  >  DATE 
C: 

C:  REGISTER  DATE  to  the  common  geographical  grid. 

C:  The  grid  points  for  the  registration  are  in  SAF198.GRD, 

C:  (MITEXT=SAF198.GRD) 

C:  which  was  created  using  MAKEGRID,  and  is  a  mercator  projection. 
C:  Use  a  degree  3  polynomial  in  the  interpolation  (DEGREER=3) 

C:  for  the  ground  control  point  transformation. 

C:  AUTORG  will  compute  the  polynomial  coefficients  and  write 
C:  a  record  named  AUTOREGN  to  the  file  TRNSMTX.DAT 
C:  The  output  image  name  from  AUTORG  is  TMP. 

C:  AUTORG  will  create  the  IDEMS  ground  control  point  file  and 
C:  attach  it  to  TMP. 

C: 

DATE  >  AUT0RG(MITEXT=SAF198.GRD,  DEGREER=3)  >  TMP 
C: 

C:  Now  do  the  actual  registration. 

C:  Register  DATE  using  the  polynomial  coefficients  generated  by 
C:  AUTORG.  These  coefficients  are  found  in  the  record  name 
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C:  AUTOREGN  (TMTXREC= AUTOREGN). 

C:  Use  a  degree  three  polynomial  in  the  transformation  (MAXTYPE=3) 
C:  The  output  image  will  be  named  DATE. CH4. REG 
C: 

DATE  >  REGISTER(MAXTYPE=3,  TMTXREC= AUTOREGN)  + 

>  DATE. CH4. REG 

C: 

C:  Convert  the  registered  image  from  Integer*2  to  byte  format. 

C:  The  land  masking  routine  (SAFMASK)  and  the  Laser  printer  must 
C:  use  a  byte  image. 

C:  Since  the  registered  image  range  of  data  is  from  0  to  1023, 

C:  re-map  these  values  from  0  to  255,  then  convert  to  BYTE  format. 

C:  AVHRR  Count  values  that  are  between  0  and  500 
C:  (  that  is  the  land  and  water  values  ) 

C:  will  be  re- mapped  from  0  to  200. 

C:  Values  that  lie  between  501  and  1023  will  be  re-mapped  to  255 
C:  (  these  are  most  of  the  clouds  ). 

C: 

DATE.CH4.REG  >  MAP(FROM=0  500  501  1023  TO=  0  200  255  255) 
C: 

C:  Convert  the  mapped  image  to  byte  (OUTYPE=BYTE)  and 
C:  name  the  output  image  DATE.CH4.CNV 
C: 

>  CONVERT(OUTYPE=BYTE)  >  DATE.CH4.CNV 
C: 

C:  Append  the  IDEMS  ground  control  point  file  created  by  AUTORG 
C:  onto  the  registered  and  byte  converted  image  DATE.CH4.CNV 
C:  and  delete  the  TMP  image. 

C: 

TMP  DATE.CH4.CNV  >  APPEND 
TMP  >  DELETE 
C: 

C:  Create  the  land  mask  from  the  gcp  file  from  DATE.CH4.CNV 

C:  land  will  equal  255,  everything  else  will  be  0 

C:  The  output  image  will  be  named  DATE.CH4.CNV.MSK 
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DATE.CH4.CNV  >  SAFMASK  >  DATE.CH4.CNV.MSK 
C: 

C:  Change  the  background  intensity  from  black  (0)  to  white  (255) 

C:  on  the  registered  byte  image. 

C:  This  is  more  “pleasing”  when  converted  to  a  QMS  laser  print 
C:  (that  is,  the  background  (areas  where  no  cloud,  land,  or  water  exist) 

C:  will  be  the  color  of  the  laser  printer  paper). 

C:  Name  the  output  image  QMSIMG.MAP 
C: 

DATE.CH4.CNV  >  MAP(FROM=  0  1  255  TO=  255  1  255)  + 

>  QMSIMG.MAP 
C: 

C:  Embed  the  land  mask  image  onto  QMSIMG.MAP  using  the 
C:  logical  OR  function.  Everything  that  is  land  will  be  white  (255) 

C:  everything  else  is  unchanged. 

C: 

DATE.CH4.CNV.MSK  QMSIMG.MAP  >  OR  >  DATE.CH4.CNV.MASK 
C: 

C:  Delete  the  temporarily  created  files. 

C: 

QMSIMG.MAP  DATE.CH4.CNY.MSK  >  DELETE 
C: 

C:  Highlight  the  water  temperature  values  and 
C:  convert  the  DATE.CH4.CNV.MASK  image  to  16  grey  level  values 
C:  This  is  an  important  step.  The  QMS  printer  can  only  create 
C:  16  different  grey  level  patterns. 

C:  To  highlight  the  Agulhas  current  values,  re-map  the  image 

C:  so  that  small  temperature  differences  in  the  current  will 

C:  represent  a  different  grey  level  value.  The  output  grey  level 

C:  values  are:  0  16  32  48  64  80  96  112  128  144  160  176  192  208  224  240  255 

C: 

C:  This  particular  mapping  table  was  created  by  trial  and  error. 

C:  Since  the  image  is  not  calibrated  to  temperature, 

C:  it  is  difficult  to  compute  the  count  value  of  the  current. 
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C:  But  using  the  cursor  to  display  the  intensity  values  of  the 
C:  image  in  the  region  of  the  current  allowed  computation 
C:  of  these  breakpoints. 

C:  The  output  image  is  named  QMSIMG.MAP 
C: 

DATE.CH4.CNV.MASK  >  MAP(FROM=  + 

0  90  91  100  101  110  111  120  121  125  126  130  + 

135  136  138  139  141  142  144  145  147  148  150  160  161  165  166  + 

170  171  175  176  195  196  255  TO  =  0  0  16  16  32  32  48  48  + 

64  64  80  80  96  96  112  112  128  128  144  144  160  160  176  + 

176  192  192  208  208  224  224  240  240  255  255)  >  QMSIMG.MAP 
C: 

C:  Insert  a  step  wedge  of  the  16  output  intensity  levels 

C:  into  QMSIMG.MAP.  The  wedge  image  has  already  been  created  and 

C:  is  named  WEDGE. 

C:  The  wedge  image  will  be  inserted  into  line  number  503  (ATLINE— 503) 
C:  and  sample  number  1  (ATSAMP=1)  of  QMSIMG.MAP. 

C:  The  output  image  is  named  DATE.CH4.IMG 
C: 

WEDGE  QMSIMG.MAP  >  INSERT(ATLINE=503,  ATSAMP=1)  + 

>  DATE.CH4.IMG 
C: 

C:  Delete  the  temporary  images  created. 

C: 

QMSIMG  QMSIMG.MAP  >  DELETE 
C: 

C:  Create  a  VAX  VMS  file  named  QMS. DAT 
C:  from  the  IDIMS  image,  DATE. CH4. IMG 
C:  in  order  to  create  a  Laser  print. 

C: 

DATE.CH4.IMG  >  DSKXFER(FILENAME=QMS.DAT) 

C: 

C:  -  END  OF  IDIMS  COMMANDS  - 
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APPENDIX  C  -  DOCUMENT 


FORMAT  SPECIFICATION  FOR 
NOAA  -  AVHRR 

COMPUTER  COMPATIBLE  TAPES  PRODUCED 
BY  THE  SATELLITE  REMOTE  SENSING  CENTRE 

OF  THE 

COUNCIL  FOR  SCIENTIFIC  AND  INDUSTRIAL  RESEARCH 


DEFINITION  OF  THE  TAPE  FORMAT 


The  General  lay-out  of  the  NOAA  AVHRR  Data  on  Computer  Compatible  Tape  is  in  accordance 
with  the  landsat  Ground  Station  Operators  Work  Group  (LGSOWG),  document  CCB-CCT-0002D. 

The  tape  format  is  as  follows  : 


VOLUME  DESCRIPTOR 
RECORD 

FILE  POINTER  RECORD  1 
FILE  POINTER  RECORD  2 

! 

FILE  POINTER  RECORD  N 


FILE  1  DESCRIPTOR  RECORD 


FILE  1  AVHRR  IMAGE 
DATA 


FILE  2  DESCRIPTOR  RECORD 


FILE  2  AVHRR  IMAGE 
DATA 


1 

1 

FILE-N  DESCRIPTOR  RECORD 

FILE  N  AVHRR  IMAGE 
DATA 


NULL  VOLUME  DESCRIPTOR 
RECORD 


SH /dir 


2/ ... 
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DATA  RECORD 


Tne  actual  AVHRR  Data  Record  has  the  following  format  : 

► 

Tne  Data  is  band  sequential,  and  from  1  to  5  channels  are  recorded  depending  on  re 
quest.  Only  complete  channels  are  recorded  on  any  particular  physical  volume,  i.i 
a  channel  is  never  split  over  two  volumes. 

The  data  can  be  8  or  10  bits  depending  on  request. 

One  record  of  AVHRR  Data  has  the  following  format  : 


BYTE 

10  BIT 

8  BIT 

< . '  1-4 

Record  NBR 

5 

355)8 

6 

355)8 

7 

22)8 

8 

22)8  ‘ 

*  '  9-12 

Record  Length 

5596 

3548 

13-  1500 

Auxi 1 i ary  Data 

1501  -  3548 

AVHRR  Data 

* 

★ 

1501  -  5596 

II  II 

★ 

The  Volume  Descriptor,  File  Pointer,  File  Descriptor,  and  Null  Volume  Descriptor  Re 
cords  are  described  below. 


SH/dlr 


3/... 
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The  volume  descriptor  is  the  first  record  of  the  volume  directory  file  (unless  pre¬ 
ceded  by  text  records).  The  contents  as  applied  to  NOAA  tapes  is  given  in  Table 
1.3.  After  the  first  16  bytes  of  general  information,  the  remainder  of  the  record 
is  composed  of  four  segments.  The  first  gives  format  documentation  and  software 
identification  for  the  format  in  which  the  superstructure  is  recorded  on  this  ta¬ 
pe.  The  second  segment  provides  basic  information  about  the  logical  volume  and 
gives  the  number  of  pointer  records  in  the  volume  directory  file.  Since  there  is 
one  pointer  record  for  each  file  in  the  logical  volume,  this  also  gives  the  number 
of  files.  The  third  segment  is  spare,  which  is  reserved  for  expansion  of  control 
information  in  future  descriptor  revisions.  The  fourth  segment,  the  local  use  seg¬ 
ment,  provides  space  for  whatever  notation  or  information  the  tape  user  wants  to 
carry  with  the  volume  directory.  The  individual  data  items  of  the  volume  descrip¬ 
tor  record  are  listed  in  Table  1.1  and  explained  in  Table  1.2. 
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TABLE  1.1 
VOLUME  DESCRIPTOR  RECORD 

BYTE  4  DESCRIPTION 

1-4  Record  number 

5  1st  record  subtype  code,  always  300)g  =  volume 
directory 

6  Record  type  code,  always  =  300)g  =  superstructure 

7  2nd  record  sub-type  code  =  077)g  if  null  volume 
descriptor,  otherwise  this  sub-type  code  =  022)g 

3  3rd  record  sub-type  code,  always  =  022)g 

9-12  Length  of  this  record 

13-14  ASCII/EBCDIC  Flag  for  this  file 

15-16  Blank 

17-28  Superstructure  control  document  number 

29-30  Superstructure  control  document  revision  number 

31-32  Superstructure  record  format  revision  letter 
33-41  Software  release  number 

45-60**  ID  for  physical  volume  containing  this  volume 
descriptor  (tape  ID) 

61-76*  Logical  volume  ID 

77-92  Volume  set  ID 

93-94  Number  of  physical  volumes  in  the  set 

95-96  Physical  volume  number,  start  of  logical  volume 

97-98  Physical  volume  number,  end  of  logical  volume 

99-100**  Physical  volume  number  containing  this  volume 
descriptor 

101-104**  First  referenced  file  number  in  this  physical 
vo 1 ume 

105-108  Logical  volume  number  within  volume  set 

109-112**  Logical  volume  number  within  physical  volume 
113-120*  Logical  volume  creation  date 

5/.. 
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TABLE  1.1 

( cont i nue) 


8YTE 

# 

121- 

128* 

129- 

140* 

141- 

148* 

149- 

160* 

161- 

164* 

165- 

168* 

169- 

260 

261- 

360 

DESCRIPTION 


121-128*  Logical  volume  creation  time 

129-140*  Logical  volume  generation  country 

141-148*  Logical  volume  generation  agency 

149-160*  Logical  volume  generation  facility 

161-164*  Number  of  pointer  records  in  volume  directory 
165-168*  Number  of  records  in  volume  directory 
169-260  Volume  descriptor  spare  segment 


*  Undefined  in  null  volume  descriptor. 

**  Fields  to  be  updated  in  a  repeated  volume  directory. 
V  B  =  binary,  A  =  Alphanumeric,  N  =  numeric 
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TABLE  1.2 


1 

l 

FIELDS 


VOLUME  DESCRIPTOR  RECORD 
DATA  FIELD  EXPLANATIONS 

EXPLANATIONS 


1  thru  6 

7 

S 

9 


10 

11 


12 


13 


14 


See  table  1.3 

The  ASCII/EBCOIC  flag  indicates  if  the  alphanumeric  informa¬ 
tion  in  the  volume  directory  file  is  in  ASC III  of  EBCDIC. 

Two  blanks. 

12  Characters  giving  the  Superstructure  Format  Control  Docu¬ 
ment  identifying  number,  i.e.,  the  number  of  that  document 
which  defines  the  current  superstructure  record  formats  and 
conventions. 

2  Characters  indicating  the  revision  number  or  letter  of  the 
Superstructure  Format  Control  Document. 

2  Characters  indicating  the  revision  letter  of  the  super¬ 
structure  record  formats.  Initially  coded  tf/A,  this  code  up¬ 
dates  one  letter  character,  alphabetical ly,  each  time  there 
is  a  change  to  the  format  of  superstructure  record  (as  oppos¬ 
ed  to  a  change  to  the  control  document  which  may  not  have 
been  a  change  in  actual  record  format).  The  26th  revision  is 
coded  AA,  the  27th  AB,  the  28th  AC,  and  so  on. 

12  Characters  identifying  the  software  version.  The  software 
referred  to  here  is  that  used  to  write  this  logical  volume. 
The  code  is  alphanumeric,  left-justified  code  assigned  by  the 
producing  facility.  It  is  updated  for  each  modification. 

This  is  a  16  character  code  also  written  or  printed  external¬ 
ly  on  the  physical  volume  and  used  to  uniquely  reference  a 
particular  CCT.  The  identification  is  the  same  for  all  logi¬ 
cal  volumes  on  the  same  physical  volume.  When  a  logical  vo¬ 
lume  spans  physical  volumes,  the  code  is  updated  for  the  con¬ 
tinuation  physical  volume(s).  (Also  referred  to  as  tape  ID). 

This  is  a  16  character  code  supplied  at  the  time  the  logical 
volume  is  recorded  and  which  can  be  used  to  uniquely  refer- 
rence  a  logical  volume  within  a  volume  set. 
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TABLE  1.2 
( continue) 


F I  ELDS 


15 


16 

17 


18 


19 


20 


21 


EXPLANATIONS 


This  is  a  16  character  code  supplied  at  the  time  the  first 
physical  volume  of  a  volume  set  is  recorded.  It  ensures  a 
unique  way  to  reference  a  volume  set  consisting  of  multiple 
physical  volumes. 

This  indicates  the  total  number  of  physical  volumes  in  a  vo¬ 
lume  set.  A  blank  field  indicates  that  the  information  is 
not  available  at  the  time  the  logical  volume  is  recorded. 

This  indicates  the  sequence  number  of  the  physical  volume, 
within  a  volume  set,  which  contains  the  1st  record  of  the  lo¬ 
gical  volume.  A  blank  field  implies  no  specific  sequence. 
The  first  physical  volume  is  numbered  as  1. 

This  will  be  the  same  as  above  unless  the  logical  volume  is 
split  across  physical  volumes.  It  indicates  the  sequence 
within  a  volume  set  of  the  physical  volume  containing  the 
last  record  of  the  logical  volume.  It  should  be  coded  blank 
if  unknown  at  time  of  recording. 

This  is  the  sequence  number  within  the  volume  set  of  the 
physical  volume  containing  this  volume  directory  file.  If 
the  logical  volume  is  completely  contained  within  one  physi¬ 
cal  volume  this  field  will  be  coded  the  same  as  field  17.  If 
it  spans  physical  volumes,  the  volume  directory  is  repeated 
at  the  beginning  of  each  tape  containing  part  of  the  logical 
volume,  and  this  field  indicates  the  tape  number  of  the  cur¬ 
rent  physical  volume. 

This  field  gives  the  file  number  within  the  logical  volume  of 
the  first  file  which  follows  this  volume  directory.  This 
can  be  larger  than  one  (the  number  of  the  first  data  file  of 
a  logical  volume)  when  a  logical  volumes  spans  multiple  phy¬ 
sical  volumes.  If  a  files  spans  two  or  more  physical  volumes 
each  portion  of  the  files  is  referenced  by  the  same  number 
(because  each  portion  is  using  the  same  volume  pointer  re¬ 
cord).  Volume  directory  files  are  not  included  in  the  file 
sequence  number  count. 

This  indicates  the  sequence  number  of  the  present  logical 
volume  within  a  volume  set.  Null  volume  descriptor  is  inclu¬ 
ded  in  this  count.  The  first  logical  volume  is  denoted  as  1. 
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TABLE  1.2 


(Continue) 

FIELDS  EXPLANATIONS 


22  This  indicates  the  sequence  number  of  the  present  logical 

volume  within  thes  physical  volume.  This  number  is  always 
present  even  in  a  null  volume  descriptor.  The  first  logical 
volume  is  denoted  as  1.  When  a  logical  volume  spans  multiple 
physical  volumes,  the  portion  of  the  logical  volume  on  this 
tape  is  counted  here  as  if  it  were  an  entire  logical  volume. 
This  rule  does  not  apply  to  filed  21  -  logical  volume  number 
within  volume  set. 

23  This  is  the  date  when  the  logical  volume  is  recorded,  expres¬ 
sed  in  years,  months  and  days.  If  multiple  logical  volumes 
are  recorded  at  different  dates  on  the  same  physical  volume, 
each  logica  volume  will  reflect  its  own  creation  date.  The 
code  is  of  the  form  :  YYYYMMDD 

24  This  it  the  time  when  the  logical  volume  is  recorded,  expres¬ 
sed  in  hours,  minutes  and  seconds.  Due  to  the  time  required 
to  record  a  logical  volume  it  is  unlikely  that  two  logical 
volumes  will  exhibit  the  same  time.  The  code  is  of  the  form 

HHMMSS 

25  Name  (or  abbreviation)  of  country  generating  this  logical 

volume. 

26  This  specifies  the  laboratory  or  center  responsible  for  the 

creation  of  the  logical  volume. 

27  This  identifies  the  computer  facility  on  which  the  logical 

volume  is  recorded. 

28  The  number  of  pointer  records  in  this  volume  directory. 

(This  automatically  indicates  the  number  of  data  files  in  the 
logical  volume). 

29  Tptal  number  of  records  in  this  volume  directory.  Equals 

number  of  pointers  plus  number  of  text  records  plus  1. 

30  This  is  the  portion  of  the  directory  which  is  undefined  and 

unused.  It  is  reserved  for  subsequent  revisions. 

31  This  js  the  portion  of  the  directory  which  can  be  used  local¬ 
ly  without  having  to  satisfy  any  common  and  approved  stan¬ 
dard.  Its  purpose  is  to  meet  local  requirements  that  are  not 
universally  recognized. 
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TABLE  1.3 
VOLUME  DESCRIPTOR  RECORD 


BYTE  # 

DESCRIPTION 

1-4 

Contains  A  1 

5 

300)  8 

6 

022 ) q  for  vol  desc  077)8  for  null  desc 

7 

022)g 

a 

9-12 

Length  of  this  record  =  360 

13-14 

AC 1 1  Flag  'AJf' 

15-16 

17-28 

' CCB-CCT-0002 1 

29-30 

'ISO1 

31-32 

•tfA' 

33-44 

•N0A2CCTV01WS' 

45-60** 

61-76* 

' DDOHHMMSS '  ( DDD=DAYS,HH=HRS ,MM=Mi ns , SS=  500 ) 

77-92 

1 NOAA  X  AVHRR0JUW'  (X  =  SAT.NBR) 

93-94 

'ii' 

95-96 

■ur 

97-98 

’j*2‘ 

99-100** 

'\Jl'  OR  'i2‘  (IF  VOL  1  OR  2) 

101-104** 

■KlAfr  OR  'MM'  (IF  VOL  1  OR  2) 

105-108 

'MU' 

109-112** 

'M  tv 

113-120* 

' 19YYMMDD'  (YY  =  YEAR ,MM=  MONTH,  DO  =  DAY) 

121-128* 

' HHMMSS '  (HH=  HOURS, MM  -  MINS,  SS  =  SEG) 

141-148* 

•S.R.S.C. ' 

149-160* 

161-164* 

'MM' 

165-168* 

'MM' 

TABLE  1.3 

(continue) 


FIELD 
Tj  NUMBER 

30 


31 


SEGMENT 

BYTE'  # 

3 

4 

169-260* 

261-360 

DESCRIPTION 


Undefined  in  null  volume  descriptor 
*  Fields  to  be  updated  in  a  repeated  volume  directory 


J  B  =  binary,  A  =  alphanumeric,  N  =  numeric. 


THE  FILE  POINTER  RECORD 


File  pointer  records  reside  in  the  volume  directory  file.  There  is  one  file  pointer 
record  for  each  data  file  of  the  logical  volume.  These  records  are  recorded  in  the 
same  sequence  as  the  files  to  which  they  point. 

The  actual  contents  of  the  file  pointer  record  are  illustrated  in  Table  2-3.  After 
the  first  16-byts  of  general  information,  there  are  three  data  segments.  The  first 
segment  supplies  information  which  points  to  (locates)  one  particular  data  file.  The 
second  segment  is  spare  and  is  reserved  for  expansion  of  the  file  pointer  information 
segment  in  future  format  revisions.  The  third  segment  provides  space  which  the  tape 
user  may  use  as  desired.  The  individual  fields  of  the  file  pointer  record  are  listed 
in  Table  2-1  and  explained  in  Table  2-2. 
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EELO 

SEGMENT 

BYTE  t 

DESCRIPTION 

1 

1-4 

Record  number 

2 

5 

1st  record  sub-type  code  =  333 ) q  pointer 

3 

6 

Record  type  code,  always  =  300)g  =  superstructure 

1  I 

7 

2nd  record  sub-type  code  =  022)g 

8 

3rd  record  sub-type  code  =  022 ) g 

9-12 

Length  of  this  record 

7 

13-14 

ASCII/EBCDIC  flag  for  the  referenced  file 

S 

15-16 

B 1  ank 

9 

17-20 

Referenced  file  number 

10 

21-36 

Referenced  file  name 

11 

37-64 

Referenced  file  class 

12 

65-68 

Referenced  file  class  code 

13 

69-96 

Referenced  file  data  type 

14 

97-100 

Referenced  file  data  type  code 

15 

101-108 

Number  of  records  in  referenced  file 

16 

1 

109-116 

Referenced  file  1st  record  length 

17 

117-124 

Referenced  file  maximum  record  length 

18 

125-136 

Referenced  file  record  length  type 

19 

137-140 

Referenced  file  record  length  type  code 

20 

141-142 

Referenced  file  physical  volume  number,  start 
of  file 

21 

143-144 

Referenced  file  physical  volume  number,  end 
of  file 

22 

145-1,52*** 

Referenced  file  portion,  1st  record  number  for 
this  physical  volume 

23 

2 

153-260 

Pointer  spare  segment 

24 

3 

261-360 

Local  use  segment 

Updated  in  repeated  volume  directory  if  logical  volume  is  split  within  a  file 
B  =  binary,  A  =  alphanumeric,  N  =  numeric. 


TABLE  2.2 


FILE  POINTER  RECORD 
DATA  FIELD  EXPLANATIONS 

EXPLANATIONS 


See  table  2.3 

A  2-byte  flag  indicating  whether  the  alphanumeric  data  in  the 
referenced  file  is  coded  ASCII  or  EBCDIC.  If  ASCII,  this 
field  is  coded  Atf;  if  EBCDIC,  it  is  coded  Efci. 

Two  blanks 

Sequence  number  within  the  logical  volume  of  the  file  refe¬ 
renced  by  this  pointer.  The  first  file  following  the  volume 
descriptor  is  file  number  1. 

A  16  character  name  which  is  the  unique  identification  provi¬ 
ded  when  the  volume  directory  is  created  in  order  to  specify 
the  file  referenced  by  the  pointer.  The  name  indicates  the 
nature  of  the  file:  header,  annotation,  imagery,  etc. 

This  is  the  description  of  the  class  to  which  the  referenced 
file  belongs.  The  class  of  a  file  is  based  on  the  nature  of 
its  content.  The  number  of  classes  should  be  open-ended  but 
limited.  Classes  which  are  essential  are  : 


Alphanumeric  and  numerical  lists 

Cellular  or  image  data 

Prof i le  data 

Polygon  data 
Isolated  data  points. 

A  file  class  indicated  a  particular  file  format  and  hence, 
knowledge  of  the  class  of  a  file  leads  directly  to  knowledge 
of  that  file's  format.  Each  file  class  has  a  class  code  as¬ 
sociated  with  it  which  is  given  in  the  next  field. 

A  4-byte  code  for  the  class  described  in  field  11. 
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TABLE  2.2 
(continue) 


F1EL0S 


EXPLANATIONS 


This  field  indentified  only  the  data;  not  the  record  intro¬ 
duction  (even  if  it  is  not  stored  in  binary  or  in  the  first 
twelve  bytes)  contained  in  the  file  through  use  of  the  fol¬ 
lowing  phrases  : 

-  8  BIT  ASCII  ONLY 

EBCDIC  ONLY 

BCD  ONLY 
BINARY  ONLY 

-  MIXED  BINARY  AND  ASCII 

-  MIXED  BINARY  AND  EBCDIC 

-  MIXED  BINARY  AND  BCD 

-  UNDEFINED,  ETC. 

Each  data  type  has  a  code  associated  with  it,  which  is  given 
in  the  following  field  (field  14). 

A  4-byte  code  for  the  data  type  described  in  field  13.  These 
codes  (given  in  the  order  of  the  phrases  above)  are  :  ASCO, 
EBCO,  BCDO,  BINO,  f«AA,  MJAE,  f«AB,  UNDF. 

This  indicates  the  number  of  records  in  the  referenced  file. 
If  this  number  is  not  known  at  the  creation  time,  then  this 
field  is  blank. 

The  length,  in  bytes,  of  the  file  descriptor  record  in  the 
referenced  file. 

This  is  the  length  in  bytes  of  the  longest  record  in  the  re¬ 
ferenced  other  than  the  file  descriptor  record.  This  is  ne¬ 
cessary  to  determine  the  memory  requirement  before  accessing 
the  file  itself. 

The  types  are  :  fixed  length,  variable  length,  undefined 
length,  and  defined  in  the  file  descriptor.  They  are  written 
as  :  FIXED  LENGTH,  VARIABLE  LEN,  UNDEFINED  LE,  and  LENGTH  IN 
FD.  The  size  of  fixed  length  records  is  given  by  field  17. 
Variable  length  records  are  smaller  than  the  maximum  size  de- 
scriber  above  and  the  actual  size  of  each  record  is  defined 
in  a  fixed  location  in  the  record  itself.  Undefined  length 
records  are  smaller  than  the  maximum  size  and  the  exact  leng¬ 
th  is  not  given  in  the  format  definition,.  It  has  to  be  ob¬ 
tained  from  other  sources.  For  some  file  classes,  variable 
length  records  have  lengths  defined  in  the  file  descriptor 
record. 


FIELDS 

19 

20 

21 

22*** 

23 

24 


TABLE  2.2 
(continue) 

EXPLANATIONS 


A  byte  code  for  the  type  describer  by  field  18.  The  codes 
are  :  FIXD,  VARE,  UNDO,  and  LIFD. 

The  number  of  the  physical  volume  within  the  physical  volume 
set  containing  the  first  record  of  the  file.  May  be  left 
blank  if  information  unknown  at  the  time  of  recording. 

The  number  of  the  physical  volume  within  the  physical  volume 
set  containing  the  last  record  of  the  file.  May  be  left  blank 
if  information  unknown  at  time  of  recording. 

When  a  portion  of  the  referenced  file  is  on  the  previous  physi¬ 
cal  volume,  this  number  is  the  record  number  of  the  first  re¬ 
cord  of  the  referenced  file  to  be  recorded  on  this  physical 
volume.  In  all  other  conditions  the  value  is  one. 

This  is  the  portion  of  the  pointer  record  which  is  undefined 
and  unused.  It  is  reserved  for  subsequent  revisions. 

This  is  the  portion  of  the  pointer  record  which  can  be  used  lo¬ 
cally  without  having  to  satisfy  any  common  and  approved  stan¬ 
dard.  Its  purpose  is  to  meet  local  requirements  that  are  not 
universally  recognized. 


*** 


Undated  in  repeated  volume  directory  if  the  logical  volume  is  split  within  a 
data  file. 


) 

I 


TABLE  2-3 
FILE  POINTER  RECORD 


!  field 

SEGMENT 

BYTE  # 

DESCRIPTION 

TYpET 

■roianwa 

J 

B 

l 

1-4 

Binary  2  to  6  (Oep.  on  Record  NBR) 

3 

2 

5 

333)8 

B 

3 

6 

300)8 

B 

4 

7 

022)8 

B 

5 

8 

022)a 

B 

6 

9-12 

360 

A 

7 

13-14 

•  A)5 1 

3 

15-16 

N 

9 

17-20 

’iilzOSr  to  'WH5'  (Dep.  on  File  NBR) 

A 

10 

21-36 

•NOAAKCHtfXtflMGY'  (X  *  1  to  5) 

A 

11 

37-64 

' IMAGER YtfF I LE *  (37:48) 

A 

12 

65-68 

' IMGY1 

A 

13 

69-96 

'  10JJB I  T^DATA^I  NK16KB I TKH-W 1  (69:93) 

A 

14 

97-100 

'BIND1 

N 

15 

101-108 

'16W LLLL '  -  (NBR  OF  LINES  +  1) 

N 

16 

1 

109-116 

1 UKKK5596 ' 

N 

17 

117-124 

•J5K  KK5596' 

A 

18 

125-136 

'  FIXED^LENGTH' 

A 

19 

137-140 

' F I XD  * 

N 

20 

'141-142 

'tV 

N 

21 

143-144 

■Kl' 

N 

22 

145-152*** 

•WMWIV 

23 

2 

153-260 

24 

3 

261-360 

***  Updated  in  repeated  volume  directory  if  logical  volume  is  split  within  a  file. 


FILE  DESCRIPTOR  RECORD 


A  file  descriptor  record  introduces  each  data  file.  The  actual  contents  of  file 
decriptor  records  are  illustrated  in  Table  3.3.  Following  the  first  16-bytes  of 
general  information  are  four  record  segments.  The  first  segments  identifies  the 
documentation  of  the  format  of,  and  the  software  version  used  to  produce,  the  data 
file  of  the  particular  application  with  which  the  superstructure  is  being  used.  In 
other  words,  while  the  segment  to  this  is  the  volume  descriptor  identifies  current 
documentation  of  the  superstructure  formats,  this  field  identifies  current  documen¬ 
tation  of  the  formats  of  the  remainder  of  the  records. 

The  second  segment  provides  the  basic  information  necessary  to  read  this  file  (the 
file  containing  this  file  descriptor  record).  The  third  segment  is  the  spare  which 
is  reserved  for  expansion  in  future  file  descriptor  revisions. 

The  fourth  segment  is  referred  to  us  as  the  file  descriptor  variable  segment.  This 
is  because  this  segment  varies  with  file  class.  Just  as  a  particular  file  class 
indicates  a  particular  file  format,  it  also  implies  a  particular  file  descriptor 
variable  segment.  The  variable  segment  for  a  particular  file  format  is  chosen  from 
among  existing  segments  if  any  apply,  or  else  it  is  defined  at  the  time  that  the 
particular  format  is  designed.  The  lay-out  of  variable  segment  for  NOAA  are  given 
in  Table  3-4,  3-5  and  3-6.  These  segments  commonly  start  with  parameters  indica¬ 
ting  the  number  of  records  of  each  record  type  in  the  file.  This  is  followed  with 
locator  information  paritcular  to  the  format  of  the  data  file,  i.e.,  how  to  access 
and  display  essential  data. 

The  data  fields  of  the  file  descriptor  record  (other  than  those  of  the  variable 
segment)  are  listed  in  Table  3.1  and  explained  in  Table  3.2. 


T  A  8  L  E  3.1 
FILE  DESCRIPTOR  RECORD 


SEGMENT 


BYTE  # 


DESCRIPTION 


1-4 

5 


Record  number 

1st  Record  sub-type  code  =  077)g  =  file 
descriptor 


1 


2 


6 

7 

8 

9-12 

13-14 

15-16 

17-28 

29-30 


31-32 
33-44 
45-48 
49-64 
65-68 
69-76 
77-80 
81-84 
'  85-92 
93-96 
97-100 
101-108 
109-112 


Record  type  code,  =  300)g  =  superstructure 

2nd  Record  sub-type  code  =  022)g 

3rd  Record  sub-type  code  =  022)g 

Length  of  this  record 

ASCII/EBCDIC  flag  for  this  file 

Blanks 

Control  document  number  of  this  embodiement 

Control  document  number  for  this  embodiement 
revision  number 

File  design  descriptor  revision  letter 
Software  release  number 
File  number 
File  name 

Record  sequence  and  location  type  flag 

Sequence  number  location 

Sequence  number  field  length 

Record  code  and  location  type  flag 

Record  code  location 

Record  code  filed  length 

Record  length  and  location  type  flag 

Record  length  location 

Record  length  field  length 


TABLE  3.1 
FILE  DESCRIPTOR  RECORD 


(continue) 


F 

ELD 

SEGMENT 

BYTE  # 

DESCRIPTION 

iTTPFjl 

NUMBER 

!  J 

1  A 

24 

- 

113 

Flag  indicating  whether  information  resulting 
from  image  analysis  is  included  within  the 
variable  segment  of  this  record 

1  A 

25 

2 

114 

Flag  indicating  whether  information  resulting 
from  image  analysis  is  included  within  this  file 

A 

1 

26 

115 

Flag  indicating  that  data  display  information  is 
included  within  the  file  descriptor  record 

!  A 

27 

116 

Flag  indicating  that  data  display  information  is 
included  within  the  file  in  record(s)  other  than 
the  fi le  descriptor 

1 

( 

23 

3 

117-180 

Reserved  segment 

1 

1 

f 

1 

i 

29 

4 

181-end- 
of  record* 

File  Descriptor  Variable  Segment 

*  Typically  the  file  descriptor  will  be  the  same  length  as  the  remaining 
records  of  the  file.  If  the  file  contains  records  of  variable  length, 
the  file  descriptor  will  be  360  bytes  in  length. 

V  8  =  binary,  A  =  alphanumeric,  N  =  numeric. 


TABLE  3.2 
FILE  DESCRIPTOR  RECORD 
DATA  FIELD  EXPLANATIONS 

EXPLANATIONS 


See  Table  3.3 

The  ASCI  I/EBCDIC  flag  indicates  if  the  alphanumeric  data  of 
this  data  of  this  data  file  is  in  ASCII  or  EBCDIC.  A  code  of 
A#  indicates  ASCII;  of  Ej6  indicates  EBCDIC. 

Two  blanks. 

12  Characters  giving  the  control  document  number  of  that  docu¬ 
ment  which  defines  this  file  format. 

2-Bytes  giving  the  revision  number  of  the  control  document  de¬ 
fining  the  current  file  format. 

2-Bytes  giving  the  revision  letter  of  the  file  format  (as  op¬ 
posed  to  revisions  which  affect  the  control  document  without 
affecting  the  file  format).  For  a  description  of  the  lettering 
scheme,  see  field  11  of  the  volume  descriptor  record.  Table  1.2 

12  Characters  identifying  the  software  version.  The  software 
referred  to  here  is  that  used  to  write  this  file,  ( i .  e . ,  to 
write  this  data  f i le) . 

Sequence  number  of  this  file  within  the  logical  volume. 

The  volume  directory  file  is  not  included  in  this  count. 

This  is  the  unique  16-character  identification  of  the  present 
file  as  stated  in  the  volume  directory  file. 

This  is  the  flag  which  indicates  whether  each  record  in  the 
file  has  a  sequence  number,  if  the  location  is  fixed  or  varia¬ 
ble,  or  if  the  count  is  cyclical.  The  file  descriptor  itself 
always  has  a  sequence  number.  It  is  not  required  for  the  other 
records.  The  allowed  codes  and  their  meanings  are  as  follows  : 

NSEQ  -  no  known  record  sequence  number  present  in  the  data 
records  of  the  fi le. 

FSEQ  -  the  record  sequence  number  is  present  in  the  same 
location  in  all  data  records  of  the  file. 


TABLE  3.2 
(continue) 

EXPLANATIONS 


VESQ  -  record  sequence  numbers  are  present  in  the  data  records 
of  the  file  but  their  locations  vary  from  record  to  re¬ 
cord. 

CSEQ  -  record  sequence  numbers  are  not  present,  at  a  cyclic 
counter  is  present,  i.e.,  each  group  of  X  records  exclu¬ 
ding  the  file  descriptor  record  in  the  file  is  numbered 
1  through  X. 

If  this  field  is  coded  NSEQ  or  VSEQ,  fields  16  and  17  are 
blank. 

If  it  is  coded  FSEQ  or  CSEQ,  these  fields  are  coded  as  follows: 

These  eight  bytes  give  the  location  of  the  start  of  the  sequen¬ 
ce  number  field.  They  give  the  record  byte  number  of  the  first 
byte  of  the  field.  (It  is  assumed  that  the  record  sequence 
number  field  falls  on  a  byte  boundary  and  consists  of  an  inte¬ 
gral  number  of  bytes). 

4-Bytes  indicating  the  length,  in  bytes,  of  the  record  sequence 
number  field. 

This  flag  indicates  whether  each  record  in  the  file  as  a  record 
type  code  and  if  the  location  of  the  code  is  fixed  or  varia¬ 
ble.  The  file  descriptor  itself  always  has  a  record  code.  It 
is  not  required  for  the  other  records.  The  allowed  codes  and 
their  meanings  are  as  follows  : 

NTYP  -  no  known  record  type  codes  present  in  the  data  records 
of  the  file. 

FTYP  -  the  record  type  code  is  present  in  the  iat,e  location  in 
all  the  data  records  of  the  file. 

VTYP  -  the  record  type  codes  are  present  in  the  data  records  of 
the  file  but  their  locations  vary  from  record  to  record. 

If'  this  field  is  coded  NTYP  or  VTYP,  field  19  and  20  are 
blank.  If  it  is  coded  FTYP,  these  fields  are  coded  as  follows. 

These  8-bytes  give  the  location  of  the  start  of  the  record  type 
code  field.  They  give  the  record  byte  number  of  the  first  byte 
of  the  field.  (It  is  assumed  that  the  record  type  code  field 
falls  on  a  byte  boundary  and  consists  of  an  integral  number  of 
bytes) . 

4-8ytes  indicating  the  length,  in  bytes,  of  the  record  type  co¬ 
de  field. 


» 

TABLE  3.2 

(continue) 

FIELDS 

EXPLANATIONS 

T - 

* 

. 

» 

, 

21 

This  flag  indicates  whether  each  record  of  the  file  has  its  re¬ 
cord  length  within  the  record,  and  if  the  location  of  the  codes 
if  fixed  or  variable.  The  file  descriptor  itself  contains  a 
record  length  field.  This  is  not  required  for  the  other  re¬ 
cords.  The  allowed  codes  and  their  meanings  are  as  follows  : 

1 

1 

NLGT  -  no  known  record  length  present  in  the  data  records  of 
the  f i 1 e . 

: 

> 

FLGT  -  the  record  length  field  is  present  in  the  same  location 
in  all  the  data  records  of  the  file. 

VLGT  -  the  record  length  fields  are  present  in  the  data  records 
of  the  file,  by  their  locations  vary  from  record  to  re¬ 
cord. 

E 

If  this  field  is  coded  NLGT  or  VLGT,  fields  22  and  23  are 
blank.  If  it  is  coded  FLGT,  these  fields  are  coded  as  follows  : 

22 

These  8-bytes  give  the  location  of  the  start  of  the  record 
length  field.  They  give  the  record  byte  number  of  the  first 
byte  of  the  field.  (It  is  assumed  that  the  record  length  field 
falls  on  a  byte  boundary  and  consists  of  an  integral  number  of 
bytes) . 

( 

23 

4-Bytes  indicating  the  length,  in  bytes  of  the  record  length 
field. 

24 

This  flag  indicates  whether  information  resulting  from  image 
analysis  is  included  within  the  variable  segment  of  this  re¬ 
cord.  The  code  for  yes  =  Y,  no  =  N. 

25 

This  flag  indicates  whether  information  resulting  from  image 
analysis  is  included  within  the  file  itself.  The  code  for  yes- 
*  Y,  no  =  N. 

r 

26 

This  flag  indicates  whether  information  necessary  to  display 
the  file  is  included  within  the  variable  segment  of  this  re¬ 
cord.  The  code  for  yes  =  Y,  no  =  N. 

27 

This  flag  indicates  whether  information  necessary  to  display 
the  file  is  included  within  the  file  itself.  The  code  for  yes 
*  Y,  no  *  N. 

ft 

■ 

I 

28 

60-bytes  which  are  held  in  reserve  for  expansion  of  file  de¬ 
scriptor  information  in  future  format  revisions. 

f 

* 

1 

29 

The  file  descriptor  variable  segment. 

* 

1 

j 

1 

1 

1 

SH/dl r 
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TABLE  3.3 
FILE  DESCRIPTOR  RECORD 


FIELD 

SEGMENT 

* 

BYTE  # 

DESCRIPTION 

TYpET 

■miif.n:! 

B 

l 

1-4 

Contains  A  1 

B 

2 

5 

077)8 

3 

3 

6 

300  )g 

4 

7 

022)8 

5 

8 

022)g 

B 

6 

9-12 

5596 

A 

7 

13-14 

'  AJ6  * 

15-16 

A 

17-28 

1 SRSC  -  NOAA-Or 

A 

10 

29-30 

*  fiJA  * 

A 

11 

1 

31-32 

•JrfA' 

A 

12 

33-44 

' N0A2CCTV01 1  (33-42) 

A 

13 

45-48 

'JSUKX'  (X  =  1-5,  DEP.  on  File  NBR) 

A 

14 

49-64 

' NOAA^CH^Xjrf I MGY '  (44-62,  X  =  1-5) 

A 

15 

65-68 

1 NSEQ 1 

N 

16 

69-76 

N 

17 

77-80 

A 

18 

2 

81-84 

' NTYP ' 

N 

19 

85-92 

N 

20 

93-96 

A 

21 

97-100 

' NLGT' 

N 

22 

101-108 

N 

23 

L 

109-112 

SH/dlr 


67 


24/.. 


TABLE  3.3 
FILE  DESCRIPTOR  RECORD 


(continue) 


ELD 

“NUMBER 

SEGMENT 

8YTE  # 

24 

““ 

113 

*  N  * 

25 

! 

114 

1  N 1 

26 

115 

1  N‘ 

27 

i 

116 

•N* 

28 

3 

117-180 

DESCRIPTION 


*  Typically  the  file  descriptor  will  be  the  same  length  as  the  remaining 
records  of  the  file.  If  the  file  contains  records  of  variable  lenqth 
the  file  descriptor  will  be  360  bytes  in  length. 

1 

J  B  =  binary,  A  =  alphanumeric,  N  =  numeric. 


SH/dlr 


TABLE  3.4 

THE  IMAGERY  FILE  VARIABLE  SEGMENT 


s 


FIELD 

SEGMENT  p 

BYTE  i* 

DESCRIPTION 

TYPE* 

Kiimuw 

N 

l 

1-6 

Number  of  image  records 

N 

2 

7-12 

Image  record  length 

3 

13-36 

Reserved  (blanks) 

PIXEL  GROUP  DATA 

N 

4 

37-40 

Number  of  bits  per  pixel 

N 

5 

41-44 

Number  of  pixels  per  data  group 

N 

6 

45-48 

Number  of  bytes  per  data  group 

A 

7 

49-52 

Justification  and  order  of  pixels  within  data 
group 

IMAGE  DATA  IN  THIS  FILE 

N 

53-56 

Number  of  images  (bands) 

N 

57-64 

Number  of  lines  per  image  (excluding  border  lines) 

N 

10 

65-68 

Number  of  left  border  pixels  per  line 

N 

11 

69-76 

Total  number  of  image  pixels  allocated  per  line 
per  band  (including  pad  pixels) 

N 

12 

77-80 

Number  of  right  border  pixels  per  line 

N 

13 

81-84 

Number  of  top  border  lines 

N 

14 

85-88 

Number  of  bottom  border  lines 

A 

15 

89-92 

Interleaving  indicator 

RECORD  DATA  IN  THIS  FILE 

N 

16 

93-94 

Number  of  physical  records  per  line 
(coded  0  if  1  ) 

N 

17 

95-96 

Number  of  physical  records  per  multipectral  line 

P 

18 

97-100 

Number  of  bytes  of  prefix  data  per  record 

H 

19 

101-108 

Number  of  bytes  of  image  data  per  record 

N 

20 

109-112 

Number  of  bytes  of  suffix  data  per  record 

A 

21 

113-116 

Prefix/suffix  repeat  flag 

*N  *  numeric 
A  -  alphanumeric 


26/., 


69 


TABLE  3.4 

THE  IMAGERY  FILE  VARIABLE  SEGMENT 


FIELD 

wtm 

A 

22 

A 

23 

A 

24 

A 

25 

A 

26 

A 

27 

m 

28 

■ 

29 

A 

30 

A 

31 

32 

M 

33 

34 

B 

35 

36 

(continue) 


BYTE  # 

DESCRIPTION 

PREFIX/SUFFIX  DATA  LOCATORS 

117-124 

Scan  line  number  locator 

125-132 

Image  (band)  number  locator 

133-140 

Time  of  scan  line  locator 

141-148 

Left-fill  count  locator 

149-156 

Right-fill  count  locator 

157-188 

Blanks 

189-196 

Scan  line  quality  code  locator 

197-204 

Calibration  indicator  average  values  locator 

205-212 

Gain  values  field  locator 

213-220 

Bias  values  field  locator 

220-252 

Blanks 

PIXEL  DATA  DESCRIPTION 

253-256 

Number  of  left-fill  bits  within  pixel 

257-260 

Number  of  right-fill  bits  within  pixels 

261-268 

Maximum  available  data  range  of  pixel  starting 
from  zero 

269-end 
of  record 

Blanks 

TABLE  3.5 

THE  IMAGERY  FILE  VARIABLE  SEGMENT  EXPLAINED 


FIELDS  EXPLANATIONS 

1  Total  number  of  image  records  in  file 

2  Length  of  image  records,  always  5596 


3 


A  blank  field  required  for  consistency  in  variable  segment 
formats 


4 

5 

6 

7 

8 
9 

10 

11 

12 

13 

14 

15 

16 

17 

18 


19 


Always  16 
Always  1 
Always  2 

Always  'RJRL'J''' 

The  number  of  images  (bands)  in  this  file  (1) 
Number  of  lines  per  image  (band) 

Always  0 

Number  of  image  pixels  per  line 
Always  0 
Always  0 
Always  0 

A  code  indicating  data  interleaving 
always  8SQ>J  =  band  sequential 


Number  of  physical  records  per  line, 
always  3  1 

Number  of  physical  records  per  line  in  this  file,  *  1 

The  length  in  bytes  of  the  per-line  prefix  support  data  field 
which  includes  scan  line  ID,  right  and  left  fill  count, 
etc. (1488) 

The  number  of  bytes  of  image  data  per  record  =  4096 


TABLE  3.5 

(continue) 


|  FIELDS 

i 

20 

21 

??•$? 

33 

!  34 

35 

36 

i 

! 


EXPLANATIONS 

The  number  of  bytes  of  suffix  support  data  (always  0) 

Always  ,RW^j^, 

Undefined 

Number  of  left  fill  bits  within  each  pixel  (6) 

Number  of  right  fill  bits  within  each  pixel  (0) 

Maximum  available  data  range  of  pixel  starting  from  zero  (255) 
Blanks  to  fill  the  record 


1 


TABLE  3.6 

THE  IMAGERY  FILE  VARIABLE  SEGMENT 


FIELD 

BYTE  # 

DESCRIPTION 

KMUiaJ 

N 

1 

N 

2 

187-192 

■15165596  ‘ 

3 

N 

I 

217-220 

'Ml6' 

N 

221-224 

'tWV 

N 

225-228 

'iui' 

A 

mm 

229-232 

'  RJRL ' 

N 

8 

233-236 

■jSlfttfl* 

N 

9 

237-244 

' MffllLLL 1  LLLL  =  Lines  Per  image 

N 

10 

245-248 

*  15  kSj60  * 

N 

11 

249-256 

'ti  tSm04B' 

N 

12 

257-260 

•MtfO' 

N 

13 

261-264 

•tJ^O' 

N 

14 

265-268 

•  jsksa’o  • 

A 

15 

269-272 

'BSQtf' 

N 

16 

273-274 

■HI' 

N 

17 

275-276 

•tfr 

N 

18 

277-280 

'  1488' 

N 

19 

281-288. 

'  151416^4096 ' 

N 

20 

289-292 

'WHO* 

A 

21 

293-296 

'RUM' 

*N  =  numeric 
A  =  alphanumeric 


T  A  8  L  E  3.6 

(continue) 


APPENDIX  A 


HRPT  Minor  Frame  Format 


! 

Function 

No. of  words 

Word 

Position 

/  Bit  No.  Plus  Word  Code  & 

123456709  10  Meaning 

1 

ID 

2 

1 

Bit  1;  0  =  internal  sync;  1  =  AVHHR  sunc 

! 

Bits  2  &  3;  00  =  not  used;  01  = 

minor  frame 

1;  10  =  minor  frame  2,  11  =  minor  frame  3 

Bits  4-7;  spacecraft  address;  bit  4  =  MSB, 

bit  7  =  LSB 

Bits  8;  0  =  frame  stable;  1  =  frame  resync  1 

1 

occured 

i 

Bits  9-10;  spare;  bit  9=0,  bit 

10  =  1 

2- 

Spare  word;  bit  symbols  undefined 

T ime  code 

4 

Bits  1-9;  binary  day  count;  bit 

1  =  MSB; 

i 

* 

bit  9  =  LSB 

!  H 

Bit  10;0;spare 

4 

Bits  1-3;  all  0's;  spare 

L 

Bits  4-10;  part  of  binary  msec  of  day  count; 

bit  4  =  MSB 

A 

vH  5 

Bit  T-10;  part  of  binary  msec  of 

day  count; 

>sw  6 

Bit  1-10;  remainder  of  binary  msec  of  day 

D 

count;  bit  10  =  LSB 

E 

Telemetry 

10 

7 

Ramp  calibration  AVHRR  channel  1 

s 

Ramp  calibration  AVHRR  channel  2 

R 

9 

Ramp  calibration  AVHRR  channel  3 

*>'  10 

Ramp  calibration  AVHRR  channel  4 

«>*11 

Ramp  calibration  AVHRR  channel  5 

KJV12 

AVHRR  channel  3  target  temp. (2^. 

Each  of  these 

!ZJ1  13 

AVHRR  channel  4  target  temp. 

words  is  a  5- 

!>*•  14 

AVHRR  channel  5  target  temp.  J 

channel  subcom 

iM15 

Channel-3  patch  temp. 

-4  words  of  IR 

VJ.W16 

00000000001  spare 

data  plus  sub- 

com  sync  (10 

O's) 

Back  scan 

30 

17 

10  words  of  back  scan  data  from 

each  AVHRR 

channel  3,  4,  and  5.  These  data 

are  time 

multiplexed  as  Chan  3 

(word  1),  chan  4  (word  1),  chan 

5  (word  1) , 

chan  3 

1 

i 

46 

(word  2),  chan  4  (word  2),  chan 

j  (word  2) ,etc . 

Space  data 

50 

47 

10  words  of  pace-scan  data  from 

each  AVHRR 

channel  1,  2,  3,  4,  and  5.  These 

data  are  time 

multiplexed  as  chan  1  (word  1), 

chan  3  (word  1) 

chan  4  (word  1),  chan  5  (word  1) 

chan  1  (word 

2),  chan  2  (word  2),  chan  3  (word  2),  chan  4 

96 

(word  2),  chan  5  (word),  etc. 

( l)  PN  =  pseudo  noise 

(?)  =  As  measured  by  a  platinum  thermometer  embedded  in  the  housing. 


APPENDIX  A 
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— 

Word 

Sit  No. 

Plus  Word  Code  & 

No. of  words 

Position 

123456789  10 

Meaning 

I 

97 

Bit  1;  0  =  AVHRR  sync 

early;  1  =  AVHRR  sync 

1  ate 

Bits  2-10;  9-bit  binary  count  of  0.9984-MHz 

periods;  bit  2  =  MSB, 

bit  10  =  LSB 

520 

98 

The  520  words  contain 

four  frames  of  TIP  data 

(104  TIP  data  words/frame) 

Bits  1-8:  exact  format  as  generated  by  TIP 

Bit  9:  even  parity  check  over  bits  1-8 

617 

Bit  10:  -bit  1 

618 

1  0  1  0  0  0  1  1  1  0 

Derived  by  inverting  the 

127 

619 

1  1  1  0  0  0  1  0  1  1 

output  of  a  1023-bit  PN 

620 

0  0  0  0  1  0  1  1  1  1 

sequence  provided  by  a 

621 

1  0  1  1  0  0  0  1  1  1 

feedback  shift  register 

622 

110  10  10  0  10 

generating  the  polynomi- 

l 

na1:  10  5  2 

X  +  X  +  X  +  X  +  1 

742 

10  0  10  110  10 

The  generator  is  started 

743 

1  1  0  0  1  0  0  0  1  0 

in  the  1 ' s  state  at  the 

744 

1  000000000 

beginning  of  word  7  of 

_ 

each  minor  frame. 
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